EnigmA Amiga Run 1997 April

home *** CD-ROM | disk | FTP | other *** search

/ EnigmA Amiga Run 1997 April / EnigmA AMIGA RUN 17 (1997)(G.R. Edizioni)(IT)[!][issue 1997-04][EAR-CD].iso / EARCD / comm / bbs / SigmaX40.lha / SampleBBS / s!x-manual < prev next >

Wrap

Text File | 1996-11-07 | 370KB | 7,083 lines

Document S!X Manual ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ S!X S Y S O P S & U S E R S (ßeta) M A N U A L by: "Doc", S!X Development REV DATE: 08-14-96 S!X VERSION: V0.39z2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE TO S!X USERS: This manual is certainly not 100% complete to MY, STEVE, or S!X DEVELOPMENT expectations! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. "I" will appreciate everyone's input as to errors, "hidden features" not documented, missing explanations, or suggestions. 2. V0.39z6 ßeta is the "1st" version to be produced in GUIDE format. Much work obviously remains creating better "Links", restructing chapters more logically, and documenting unexplained features. 3. Please send your "Reports", "Comments", S!X "Utils" to either of the following addresses. The quality of the FINAL S!X MANUAL depends entirely on the feedback and co-operation I receive. Doc, S!X Development BBS: Doc's Houses 614-855-3114 NET: gagreen@iwaynet.net 4. "Coding" for known defects to be corrected: <ERRATA> = "Errors" reported...or manual seems incorrect <KORECT> = Manual needs better explanation <NO_DEF> = Feature not defined or documented <VERIFY> = Verify if feature is working 100% as documented <FROM:> = REVISION.DOC entrys not yet incorporated <BUG> = "Erratic Behavior" or "Bug" reported C O N T E N T S Chapters: ~~~~~~~~ (1)............................. /X & S!X History (2)................................. Requirements (3)................................. Installation (4)...............Configuring S!X via ACP,STARTUP (5)........ Explanation of ACP.STARTUP Parameters (6)...........Configuring S!X using GUI CONFIG(x) (7).......... Install S!X in you Startup-Sequence (8)...................... Controlling S!X via ACP (9)............. S!X "Extended Conferences" Setup (10)................. Using the S!X Account Editor (11).........S!X "Program Logic" OR "HOW IT WORKS! (12)..........S!X "User Menu Commands" You Can Use (12.1).....S!X "Online Help System" Creation/Usage (13)......."Custom Commands" File Format Setup/Use (13.1)......DIZ-EXTRACT File Identification System (13.2).....Using new BBS:SYSTEMS Commands with S!X (13.3).....Using new BBS:Commands/ "Internal Cmds! (14)...........(MCI) Macro Command InterPreter Use (14.1)Using BBSTexts to Display Screens/Texts/ANSI (14.2)Using Special <FileNames> to Control Node(s) (14.3)..Using Conf() Specific Texts/Commands/Bulls (15).....S!X Doortypes and Programmer's Semiphores (16).......Misc. Information on /X and S!X Systems 1. CHAPTER 1 Historical Commentary: by Doc ============================================= ************************************************************** CHAPTER 1 Historical Commentary: by "Doc" ************************************************************** Having been a part of the evolution of all version of /X and S!X since its inception, let me give you a short overview of how all the Ami-Expres and S!X-EXPRESS variations were developed. I have personally worked with all these gentlemen over the past SIX (6) years. This short commentary is a public acknowledgement of each's contribution PAST, PRESENT, and FUTURE to Amiga BBS systems. WHAT IS "/X" and "S!X" ? /X and S!X are BBSs, commonly called Bulletin Board Systems, allowing the transfer of data, between host (S!X) and remote computers (known as terminals or "users") via telephone or NULL MODEM LINK. The data can be files, electronic mail (E-Mail), and many other services such as: "Online Games" "FAX" "NetMail" and other features similar to any modern telecommunications system. HOW DID THEY ALL ORIGINATE ? The history of S!X and its "cousins" originates with Mr. Chuck Maier's (TAG-BBS) who made his source code publicly available. The "Original Ami-Express" (/X V0.9 - V1.1t) was created by Mike Thomas to demonstrate his programming skills to obtain professional work with Amiga programming. Mike is a former employee of GVP, most noted for his GVP G-Force II and other installation programs. V2.0 - V2.34 were developed by Joe Hodge. Mr. Hodge served in the US Air Force while developing his C programming skills. He left military service to found Light Speed Technologies with a view of converting Ami-Express into a commercial program. Joe released the source codes to V2.34 and V3.08 Beta in June 1992 to the PUBLIC DOMAIN. He continues developing V3.0 and V4.0 versions of Ami-Express as a commercial program Spastic-Express is a PRIVATE CLONE developed by Mr. Ron Shaw. Mr. Shaw is a former engineer, a programmer for NASA, and a private computer freelance writer residing in Floria. This version is not Publicly available. S!X-Express is developed by Mr. Stephan Schiemann, a German programmer. Stephan (Steve to English friends) is a gentleman like Mr. Thomas; a gifted young programmer demonstrating his programming talents to enhance his professional reputation. S!X is the only version which is FREEWARE and PUBLICLY SUPPORTED via various BBS systems and direct contact with members of S!X Development via InterNET. WHAT IS PLANNED IN THE FUTURE ? Mr. Hodge claims all variations of Ami-Express V3.0+ to be COMMERCIAL and works on Ami-Express V4.7 as an income producing COMMERCIAL ENTERPRISE. I left my association with Mr. Hodge with V2.34+ due to this view; we wish him well in his future. Mr. Shaw continues to develop his PRIVATE VERSION for personal enjoyment and amusement. Ron is a close personal friend with serious medical disabilities; he has had at least three highly successful careers in industry prior to his present medical difficulties. Therefore he will likely continue his private variant for personal satisfaction. Mr. Schiemann is extremely active with S!X Development. He works closely with a few trusted associates in PROGRAMMING, DESIGN, TESTING. He also openly trades technical and programming ideas and sources with developers of other BBS Systems such as Tempest BBS. Steve has stated, "S!X will always be FREEWARE. It will never become a COMMERCIAL PROPERTY. I may someday have to ask for a small honorarium to offset costs of supporting users, but even this will be a nominal fee which no one will be obligated to pay to obtain or use S!X." (Steve means a small contribution to offset phone, mail, expenses incurred for DIRECT SUPPORT). Ohh....I am Gregg Green (aka "Doc" or "GeeZER"). "Doc", S!X Development ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A Personal "Introduction Letter" to S!X SysOPS and Users Written by: Steve Schiemann (Sigma-SEVEN!) and Gregg Green (Doc) Hi. My name is Steve. Many of you know me as Sigma-SEVEN!, the author of S!X BBS. I am taking a few minutes from coding the program to talk to you, explaining what I am trying to accomplish for the entire Amiga community. I live in Germany and am presently unemployed (PLEASE TELL POTENTIAL EMPLOYERS YOU KNOW). I started coding utils for Ami-Express a few years ago as a hobby. Having become disenchanted with the direction which Joe Hodge was taking, I decided to take the Public Domain sources and develop an alternative while increasing my knowledge of programming. I do not claim to be an expert programmer. S-Express is being developed as I learn. Therefore, some of the things which I certainly would like to do are unfinished. I hope everyone understands that this project is my means to sharpen my skills, gain exposure in the community as a reasonably skilled programmer, and continue to increase my knowledge of programming. I believe my program should be more than merely a way to exchange files. It should be, were I more capable, a complete communications systems allowing for InterNET, TeleNET, FAX, Fido, and complete remote control control. I can not promise anyone that all these features will ever be realized. Nevertheless I work on ideas and coding regularly; ideas which I know can be completed using the best programming skills and producing fast, tight executables. My goal is completing my education and gaining respect for my skills. By skills I do not mean merely coding; moreso I mean my ability to write a system which is quality and logical to both the system operator (SYSOP) and the user. A system should be complete, flexible, logical, and easy to operate and understand. It should look and feel professional if I am to be respected for understanding your needs and wants. I am working toward these goals, including working with others who are writing "Express Utils" and other alternate versions. I hope people respect my efforts and will realize this is a hobby, not my job. I promise to continue development slowly as my time permits, listen to your ideas, and never make a program which I feel is not the best quality within my capabilities. Stephan (Steve) Schiemann aka: Sigma-SEVEN! Hi. Friends call me "Doc", but my real name is Gregg. I've been involved with Ami-Express ever since Mike Thomas's V0.9ß-V1.1w; later I worked with Joe Hodge on V2.0-V2.34 until he switched to "icons". I am not a genius of Amiga programming either. My background is in software systems designs. I live in the USA and own two businesses in construction/development and a professional business consultinf firm. Therefore I am the "old, gray man" around here, being 49 in March '96. My goal has always been to help programmers hone and market their skills in industry; this is the reason Mike Thomas and I became good friends. I find Sigma (Steve) has the same type personality as Mike. He has an instinct and insight into what is really quality, and he has the potential to reach the level of Chris Hames, Geroge Hormann, and others I've been privledged to know and help. I am here to help Steve design S-Express, and to help any 3rd party coders develop new ideas and improve present utils. "Express" is sorta my baby I guess. So helping people development themselves while seeing it mature is fun and worth the hours spent on various design ideas. I keep a large collection of completed S-/X utils on my BBS, and serve as a "Tech Support & ßeta Site" for new versions of both S-/X and utils which we have tested for compatability. That way Steve and others can concentrate on improving the system for all of us. Gregg Green aka: Doc 2. CHAPTER 2 Requirements Needed to Use S!X-Express =================================================== ************************************************************* CHAPTER 2 Requirements Needed to Use S!X-Express ************************************************************* Due to the flexible design of S!X-Express which is primarily based upon Mike Thomas's V0.9 - V1.1t,Joe Hodge's V2.0 -V2.34 series, and Steve's gifted talents in blending all these variants compatably there are numerous ways to INSTALL or UPDATE from Ami-Express to S!X-Express. S!X-Express is installed via: S!X Modular Install Packages 1. There are "combined" and "separate" packages developed for conversion of the following /X versions: a. Ami-Express V0.9 - V1.1t b. Ami-Express V2.0 - V2.34+ c. Ami-Express V3.0 - V4.7+ (including "encrypted" USER.DATA) 2. "NEW INSTALLATIONS" are also accomplished by S!X Modular Install Packages. These packages are designed to be extremely user- friendly and explain each step of S!X INTALLATION or UPDATING from a previous version. a. S!X Modular Install Packages - are available via any of our "Support Sites". At each site a highly knowledged S!X Development Team Member is there to assist with installation, technical problems, questions, or offer assistance to the SysOP. =================================================================== Any program has certain SYSTEM REQUIREMENTS, S!X is no exception. It is obvious you must own an Amiga computer (although "emulators" may be developed to emulate correctly the Amiga OS in the future) REQUIREMENTS FOR SUCCESSFUL OPERATION: 1. Amiga 500, 2000, 2500, 3000, 1200, 4000 computer 2. AmigaDOS OS V2.04+ Kickstart V2.04+ a. S!X "Highly Suggests" you have at least V2.10+ of both the AmigaDOS OS and Kickstart due to technical difficulties with original CBM Releases of Version 2. b. S!X is best operated with AmigaDOS V3.0+/V3.1 OS, due to advanced features offered in these versions. While all main features are functional, several "enhanced functions" may not be available OR not supported in future versions except in DOS OS V3.0+ 3. RAM: You should have at least 2 MEGAbytes of FREE RAM to operate S!X successfully. a. At least 1 MEGAbyte should be of "FASTRAM". This is to speed operations and allow certain operations to occur to RAM: versus disk operations. b. Add @250K RAM: for each NODE you wish to operate via telephone lines for fastest operation. 4. High Speed Modem. Presently we consider USR HST 14.4 DUAL, HAYES, and similar modems to be minimum requirements in this day of high-speed data transmission. 5. I/O CARD is REQUIRED for "Multi-Noding" at high speed. These can be of the GVP, ASDG, or other high-quality varieties. 6. "STORAGE" While S!X could be operated having enough RAM, it is an impracticality with high-speed BBS systems. There are now several methods of FILE/MESSAGE storage available to Amiga owners. These are combinations of TAPE, CD-ROM, HD, RAM. Therefore I will only outline "General Requirements" common today among successful BBS Systems. a. BBSs must be able to READ/WRITE a large amount of data and retrieve it very quickly. While requirements vary from SITE to SITE, here are some general basics: 1. AT LEAST: 100 MEGAbytes of HD or READ/WRITE TAPE which is a valid AmigaDOS device. The main point to consider is "Writing" space. If you wish to transfer MAIL/FILES, you will need much space....the more activity on your system the more space needed for callers to "WRITE" to your storage devices. 2. BULK: This can be accomplished via either a TAPE or HDrive in the 200-1400 MEG range, or via CD-ROM for sites offering files primarily available via ROM disks. 7. Beginning with S!X V0.39p (04-17-95) a KEY FILE is required to be placed in your BBS: directory. As yet, no part of the program is "crippled". It merely says you're running an UNREGISTERED VERSION.........this is to encourage everyone using S!X to let us know who/where/how/why you like our work. BBS:SigmaExpress.key ( MUST EXIST AS: BBS:SigmaExpress.key) 8. AE.LIBRARY has been removed from S!X for quite a while. However some "Doors" still require this library, so you should have it. 9. LOCALE.LIBRARY and FIFO.LIBRARY are required for S!X. "Locale" is required due to the sexpress.cd/sexpress.ct/sexpress catalogue system to have multiple language support. FIFO.LIBRARY is used now with "Doors" and other parts of S!X to make using of all its features in "pipings": EXAMPLE "Doors" "FCheck" 3. CHAPTER 3 S!X Installation or Conversion from /X Versions ============================================================ ************************************************************* CHAPTER 3 S!X Installation or Conversion from /X Versions ************************************************************* ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: S!X "NEW INSTALLATION" or conversion from an Ami-Express version are all handled via S!X Modular Install Packages. Therefore I will not discuss how to physically install of update S!X files to your system , but refer you to these S!X Modular Installation Packages documents which contain a detailed explanation. complete documentation. Once the physical files are installed or updated, you will need to make or update the following to your S:Startup-Sequence or S:user-startup ---S:Startup-Sequence "Additions"--- ASSIGN BBS: <Path>:BBS ASSIGN DOORS: <Path>:Doors PATH BBS: BBS:MYUTILS BBS:UTILS ADD RUN >NIL: ACP ---END "Additions"--- Once all of this is complete you should be able to reset your system. 4. CHAPTER 4 Configuring S!X via: ACP.STARTUP ============================================== ************************************************************* CHAPTER 4 Configuring S!X via: ACP.STARTUP ************************************************************* ACP.STARTUP is the most common controller for S!X entire setup, parameter definitions, initialization, and operation. It is critical to understand the S:ACP.STARTUP variables; you can control almost every action of S!X with your choices via ACP.STARTUP. Therefore we will go through a "VERY DETAILED EXPLANATION" of all the ACP.STARTUP parameters, explaining what each is and does. (Experienced S!X -or- /X SysOPS are advised to read this as) (many new features or changes have evolved in this release..) ================================================================== *****NOTE ME SPECIAL CAVEAT**** DO NOT!!!!....REPEAT NOT!!!!....put "comments" in your ACP.STARTUP file without discussion with an S!X Development Team Member !!!!!! THIS **WILL CAUSE** FAILURE!!!!!!! Filenotes or comments in this manual are for explanation purposes and ***SHOULD NOT APPEAR*** in your ACP.STARTUP ================================================================== 1. "SAMPLE" ACP.STARTUP [SEE **CAVEAT** ABOVE RE: "comments"!!!] ; S!X V0.39+ "DEMO RELEASE" acp.startup ; ; 1. ***NOTE ME*** Many of the ACP.STARTUP commands are ; "sensitive" to the order in which they appear in the ; acp.startup sequence. WE HAVE GROUPED THEM "AS ; BEST AS POSSIBLE" so the setup is logical. ; ; 2. ***NOTE ME*** We have put ";" COMMENTS on many of ; these entries as explanation. ****CAVEAT*** Some ; commands will fail with comments on the same ; line as the command (even if ";" is exactly at ; end of the <CMD STRING>. WE HOPE TO "FIX" THIS ; INCONVENIENCE IN FUTURE REVISIONS....but due to ; the way all the "/X" and "S!X" read acp.startup ; you should not use COMMENTS without technical help. ; ; ; "INITIAL ACP STARTUP STRINGS TO GET THINGS GOING" ACP_PRIORITY 12 ;TaskPRI to run ACP Controller ITOP 557 ;TOP EDGE (pixel) ACP Controller ILEFT 0 ;LEFT EDGE (pixel) ACP Controller NUMBER_OF_NODES 2 ;# active NODE(S) you're running NODE* LEFTEDGE 0 ;Node(x) LEFT EDGE SCREEN (pixel) NODE* TOPEDGE 0 ;Node(x) TOP EDGE SCREEN (pixel) NODE* WIDTH 724 ;NODE(x) WIDTH (FOR: HIres PAL) NODE* HEIGHT 565 ;NODE(x) HEIGTH (FOR: HIres PAL) NODE* BITPLANES 3 ;1=2color 2=4color 3=8color 4=16color ;NODE* ACTIVATE_WINDOW ;ON=Start "Active" OFF="Iconified" ;NODE0 IDLENODE ;ON= NODE(0) idle at ACP start ;NODE1 IDLENODE ;ON= NODE(1) idle at ACP start STARTNODE0 BBS:utils/express >NIL: 0;Start BBS NODE(0) running STARTNODE1 BBS:utils/express >NIL: 1;Start BBS NODE(1) running ;NODE3 TRAPDOOR ;Node() started via TrapDoor program ;LOADCONFIG ;Use CONFIG and Config(x) loading ;PUBLICSCREEN AEBench ;Specify (Screen) for S!X...DO NOT ; ;use w/ running CustomSCREEN PAL on ; ;NTSC w/ Amiga2PAL, etcitera. ;NODE* INTERLACE ;***CAUTION*** This is probably ; ;already set by your PREFS: or ; ;other Custom "Startup" commands. ; ; "BASIC DEFINITIONS OF DIR(x) and FILE LOCATIONS IN BBS:" ; NODE* BBS_LOCATION BBS: ;This should be "ASSIGNED" ;in your 'startups' such ;as ASSIGN BBS: DH0:BBS NODE* USERDATA_LOCATION BBS:User.Data ;USE THIS...or most "Doors" ;and utils **WILL FAIL**! NODE* USERKEY_LOCATION BBS:User.Keys ;Location of USER.KEYS ;(see caution as USER.DATA) ;NODE* NEW_USER_PASSWORD NewPass ;"New" Applicants can't ;logon without PASSWORD ;which here is: "NewPass" NODE* SYSTEM_PASSWORD YES ;Requires PASSWORD to ;enter. (See PRIVATE.TXT) NODE* BBS_NAME [[44;33mDoc's House, S!X Development Team[[0m NODE* SYSOP_NAME Doc ;**MUST BE SLOT(1) NAME** NODE* GEOGRAPHIC_LOCATION Doc's House...S!X Development & Support ;NODE* SHUTDOWN_BATCH S:BBSshutdown ;Execute on Node(x) "SHUTDOWN NODE* LOGOFFBATCH S:upscript ;Executed on each LOGOFF ;NODE0 PLAYPEN hd1:playpen ;***NOTE ME*** Put here to ;remind that PLAYPEN can ;now be anywhere!! NODE0 PLAYPEN bbs:node0/playpen NODE1 PLAYPEN bbs:node1/playpen NODE0 RINGCOUNTS 1 ;***MUST BE SPECIFIED*** ;NODE1 RINGCOUNTS 0 ;for all 'phone lines'. ;Does not apply to your ;'Local Node()'. ;NODE* LOCAL_UL_PATH dh2:myprojects ;"Local" F1 UPLOAD path ;NODE* ICONIFY ;**NOTE** This must be LAST ; ;ENTRY in "Window Specs" to ; ;start both ACP/NODE(s) in ; ;an "Iconified" state. ; ; "BASIC =Initialization= COMMANDS TO YOUR MODEM" ; ;NODE0 A2232_PATCH ;Patch if you own A2232! NODE0 UNIT 0 ;(See your telecom manual!) NODE0 DEVICE_DRIVER serial.device ;You *CAN* use others such ; ;as baudbandit.device ;NODE0 MODEM_OFFHOOK ATM0H1 ;"Busy" line NODE is off! NODE0 MODEM_INIT ATB0E0F1M1Q0V1X6S0=0S2=255S7=40S12=255&G2 ; ;***ABOVE WILL VARY***... ; ;check your MODEM MANUAL!! NODE0 TASK_PRIORITY 12 ;TaskPRI to run NODE(0) NODE0 INIT_BAUD 38400 ;Node(0) start BaudRate NODE0 SERIAL_BUFFER_SIZE 4096 ;Node(0) StackSize NODE0 MODEM_RESET ATH0 ;Modem RESET string NODE0 MODEM_RING RING ;"Ring" NODE0 MODEM_ANSWER ATA ;"Answer" command NODE1 UNIT 1 ; ;NODE1 DEVICE_DRIVER ;**NOTE** "Local" nodes ;NODE1 MODEM_OFFHOOK ;do not need to specify ;NODE1 MODEM_INIT ;these parameters. NODE1 TASK_PRIORITY 3 ;"Local" Node(1) TaskPRI NODE1 INIT_BAUD 76800 ; ;NODE1 SERIAL_BUFFER_SIZE ;N/A...not using SER: ;NODE* MODEM_HARDFLUSH ;Used w/ some modems...check! ;NODE* TRUE_RESET ;Resets with DTR hangup and ; ;later MODEM_INIT initized ; ;This takes a little time!! NODE0 CONNECT_300 CONNECT ;"Connect" strings" NODE0 CONNECT_1200 CONNECT 1200 ;"Connect" 1200 baud string NODE0 CONNECT_2400 CONNECT 2400 ; NODE0 CONNECT_4800 CONNECT 4800 ; NODE0 CONNECT_9600 CONNECT 9600 ; NODE0 CONNECT_14400 CONNECT 14400 ; NODE0 CONNECT_16800 CONNECT 16800 ; NODE0 CONNECT_19200 CONNECT 19200 ; ; "DESCRIBE AND DEFINE OUR SYSTEM'S 'Conferences'" NODE* CONF_NAME 01-NEWapps NODE* CONF_LOCAL 01-BBS:NEWapps/ NODE* CONF_NAME 02-AmiDOCS NODE* CONF_LOCAL 02-BBS:AmiDOCS/ NODE* CONF_NAME 03-AmiUTILS NODE* CONF_LOCAL 03-BBS:AmiUTILS/ NODE* CONF_NAME 04-AmiGRAPHICS NODE* CONF_LOCAL 04-BBS:AmiGRAPHICS/ NODE* CONF_NAME 05-AmiMUSIC NODE* CONF_LOCAL 05-BBS:AmiMUSIC/ NODE* CONF_NAME 06-AmiBUSINESS NODE* CONF_LOCAL 06-BBS:AmiBUSINESS/ NODE* CONF_NAME 07-AmiEMULATORS NODE* CONF_LOCAL 07-BBS:AmiEMULATORS/ NODE* CONF_NAME 08-AmiAGA_EGS NODE* CONF_LOCAL 08-BBS:AmiAGA_EGS/ NODE* CONF_NAME 09-AmiTELECOM NODE* CONF_LOCAL 09-BBS:AmiTELECOM/ NODE* CONF_NAME 10-AmiVIP NODE* CONF_LOCAL 10-BBS:AmiVIP/ NODE* CONF_NAME 11-Program_ASM NODE* CONF_LOCAL 11-BBS:Program_ASM/ NODE* CONF_NAME 12-Program_C NODE* CONF_LOCAL 12-BBS:Program_C/ NODE* CONF_NAME 13-Program_E NODE* CONF_LOCAL 13-BBS:Program_E/ NODE* CONF_NAME 14-ibmDOS NODE* CONF_LOCAL 14-BBS:ibmDOS/ NODE* CONF_NAME 15-ibmWINDOWS NODE* CONF_LOCAL 15-BBS:ibmWINDOWS/ NODE* CONF_NAME 16-ibmVIP NODE* CONF_LOCAL 16-BBS:ibmVIP/ NODE* CONF_NAME 17-Mac NODE* CONF_LOCAL 17-BBS:Mac/ NODE* CONF_NAME 18-MacVIP NODE* CONF_LOCAL 18-BBS:MacVIP/ NODE* CONF_NAME 19-FOR_SALE NODE* CONF_LOCAL 19-BBS:FOR_SALE/ NODE* CONF_NAME 20-InterNET NODE* CONF_LOCAL 20-BBS:InterNET/ NODE* TOTAL_CONFERENCES 20 ; "DEFINE 'User Accesses' TO USE CERTAIN S!X FEATURES" NODE* EALL_LEVEL 200 ;LEVEL to write "EALL" messages NODE* QUIET_NODE 200 ;QUIETS Node & Hides User from WHO NODE* WHO_FILENAMES 200 ;Level to see U/Ds from S!X WHO NODE* ACCOUNT_EDITING 255 ;Account Editing NODE* BULLETINS 3 ;READ BULLETINS NODE* COMMENT_TO_SYSOP 3 ;use "C" command to write to SYSOP NODE* DOWNLOAD 10 ;D/L files from S!X FileDir(s) NODE* ENTER_MESSAGE 10 ;WRITE Messages to other MEMBERS NODE* FILE_LISTINGS 3 ;"View" Dir(x) Listings NODE* JOIN_CONFERENCE 10 ;"Change" to a new CONFERENCE NODE* NEW_FILES_SINCE 10 ;use see NewFiles Since Last Call NODE* PAGE_SYSOP 30 ;PAGE SYSOP NODE* READ_MSG 3 ;READ Messages (except PRIVATE MAIL) NODE* REMOTE_SHELL 255 ;use Remote AmigaDOS SHELL NODE* DISPLAY_USER_STATS 3 ;see your User STATS NODE* UPLOAD 3 ;UPLOAD Files to BBS NODE* VIEW_A_FILE 3 ;VIEW a file ONLINE NODE* EDIT_USER_INFO 10 ;use "W" command to EDIT your info NODE* EDIT_USER_NAME 255 ;use "W" command to CHANGE YOUR NAME NODE* EDIT_USER_LOCATION 255 ;use "W" command to CHANGE LOCATION NODE* EDIT_PHONE_NUMBER 255 ;use "W" command to CHANGE PHONE # NODE* EDIT_PASSWORD 10 ;use "W" command to CHANGE PASSWORD NODE* ZIPPY_TEXT_SEARCH 10 ;Search Dir(x) for file by <string> NODE* OVERRIDE_CHAT 100 ;PAGE SYSOP when CHAT is OFF!! NODE* CHAT_COLOR_SYSOP 33 ;Color SYSOP is in CHAT (Color ON) NODE* CHAT_COLOR_USER 35 ;YOUR Color in CHAT (Color ON) NODE* START_0300_TIME 0 ;Start Time 300 callers=MIDNIGHT NODE* END_0300_TIME 0 ;**IF START=END** NO CALLERS!! NODE* START_1200_TIME 0 ;Start Time 1200 NODE* END_1200_TIME 0 ;**NO 1200** because START=END NODE* START_2400_TIME 0 ;Start 0 = Midnight NODE* END_2400_TIME 2359 ;End 2400 = 11:59PM 2400 ALWAYS!! NODE* START_9600_TIME 0 ;***NOTE*** 0=2359 means ANYTIME!! NODE* END_9600_TIME 2359 ;or ALWAYS ACCEPTED (Militart Time) NODE* START_14400_TIME 0 ;HST or HSpeed Start NODE* END_14400_TIME 2359 ;HST or HSeeed Stop NODE* START_16800_TIME 0 ;""Same"" NODE* END_16800_TIME 2359 ;""Same"" NODE* START_19200_TIME 0 ;HST or HSpeed Start NODE* END_19200_TIME 2359 ;HST or HSpeed Stop ALWAYS!! NODE* OVERRIDE_TIMES 100 ;OverRides Start-End Time w/ ACCESS LEVEL NODE* SYSOP_READ 200 ;To read **ALL MESSAGES (even PRIVATE) NODE* KEEP_UPLOAD_CREDIT 2 ;Credit USER for U/L + Extra Time ALL DAY ; ; "PRESETS" TO DEFINE 'Members' ACCESS LEVESL VIA ACCOUNT EDITOR" ; <ERRATA> Almost "Bet" this doesn't work by allowing you to put the extra <ERRATA> fields direct into ACP.STARTUP.....but would be must easier/cleaner <ERRATA> way of handling this damn mess!!! <ERRATA> **VERIFIED!!!*** ACP and ACP.STARTUP can't read anything past the <ERRATA> (9) conferences. Ouch....the Areanames/xxx___x_ files are a very <ERRATA> ugly way to do it and leads to massive "LOGIC ERRORS". NODE* PRESET_ACCESS_LVL 01-20 NODE* PRESET_RATIO_TYPE 01-0 NODE* PRESET_RATIO 01-3 NODE* PRESET_DAILY_BYTES 01-20000000 NODE* PRESET_CONF_ACCESS 01-XXX______ ; NODE* PRESET_CONF_ACCESS 01-NEWUSERS NODE* PRESET_TIME_LIMIT 01-2700 NODE* PRESET_ACCESS_LVL 02-5 NODE* PRESET_RATIO_TYPE 02-0 NODE* PRESET_RATIO 02-1 NODE* PRESET_DAILY_BYTES 02-10000000 NODE* PRESET_CONF_ACCESS 02-X________ ; NODE* PRESET_CONF_ACCESS 02-BADBOYS NODE* PRESET_TIME_LIMIT 02-1800 NODE* PRESET_ACCESS_LVL 03-30 NODE* PRESET_RATIO_TYPE 03-0 NODE* PRESET_RATIO 03-5 NODE* PRESET_DAILY_BYTES 03-30000000 NODE* PRESET_CONF_ACCESS 03-XXXXX____ ; NODE* PRESET_CONF_ACCESS 03-NORMAL NODE* PRESET_TIME_LIMIT 03-3600 NODE* PRESET_ACCESS_LVL 04-100 NODE* PRESET_RATIO_TYPE 04-0 NODE* PRESET_RATIO 04-5 NODE* PRESET_DAILY_BYTES 04-99000000 NODE* PRESET_CONF_ACCESS 04-XXXXX_X_X ; NODE* PRESET_CONF_ACCESS 04-TOPGUNS NODE* PRESET_TIME_LIMIT 04-5400 NODE* PRESET_ACCESS_LVL 05-200 NODE* PRESET_RATIO_TYPE 05-0 NODE* PRESET_RATIO 05-5 NODE* PRESET_DAILY_BYTES 05-99999999 NODE* PRESET_CONF_ACCESS 05-XXXXXXX_X ; NODE* PRESET_CONF_ACCESS 05-COSYSOPS NODE* PRESET_TIME_LIMIT 05-99999 NODE* PRESET_ACCESS_LVL 06-255 NODE* PRESET_RATIO_TYPE 06-0 NODE* PRESET_RATIO 06-5 NODE* PRESET_DAILY_BYTES 06-99999999 NODE* PRESET_CONF_ACCESS 06-XXXXXXXXX ; NODE* PRESET_CONF_ACCESS 06-S!X NODE* PRESET_TIME_LIMIT 06-99999 ; ; "TOGGLE SWITCHES" TO CHANGE S!X OPERATIONS ; ;NODE* RELATIVE_CONFERENCES ;Make Conf(s) "Relative" NODE* SENTBY_FILES ;Write SENT BY: <user> in Dir(x)s NODE* DEFAULT_CHAT_ON ;"Chat" (PAGE SYSOP) ON as DEFAULT NODE* BREAK_CHAT ;CTRL-C breaks out of "Chat" mode NODE* CLEAR_SCREEN_MSG ;Does ClearScreen between Messages NODE* ALLOW_FREE_RESUMING ;Allow resuming "INCOMPLETE" U/Ds NODE0 DO_CALLERSLOG ;Write "Callerslog" ONLY NODE(0) NODE0 DO_U/D_LOG ;Write "UDlog" ONLY for NODE(0) NODE* STARTLOG ;S!X "Initialization" log report NODE* DOORLOG ;S!X "Door" activity log report NODE* SCREEN_TO_FRONT ;Screen to Front on USER Logon NODE* STATBAR ;ON=Use StatusBar on Node(x) NODE* DIR_IN_KBYTE ;Display in "KBytes" not "Exact" ;NODE0 NO_TIMEOUT ;ON=Disables Auto-Logoff TIMEOUTS NODE1 NO_TIMEOUT ;"Local" set ON; "Phone" set OFF NODE* SUPPRESS_QLOGON ;ON=Disable bypass Logon Screens NODE* STEALTH_MODE ;ON=Ask PW before any displays NODE* QUIETNODE ;Activate "WHO" blocking capacity ;NODE* CAPITOLS_IN_FILE ;ON=USE CAPITAL LETTERS in dir(x) ;NODE* NO_MCI_MESSAGE ;ON=Disables all ~MCI Commands ;NODE* NO_WILDCARDS ;Turns off (*) WildCard Downloading ;NODE* CONFERENCE_ACCOUNTING ;NEW V0.39m4 ;NODE* CENTRAL_HOLD ;NEW V0.39m4 All holds to one DIR? ; ; "BUTTONS-n-NUTTONS" ACP COMMANDS YOU CAN SET YOURSELF" ; ;NUTTONS require NODE selection ; ;COL24 MUST BE "|" or else your FAIL!!! ; ; ;BUTTON01: AXVal |run >con:0/0/640/100//CLOSE axval <* BBS: 2 WAIT ;BUTTON02: SalvUser |run >con:0/0/640/100//CLOSE salvuser <* ACP ;BUTTON03: AERegCards |runback dh1:amigadex/amigadex s:AEREG.CARDS ;BUTTON04: LaDraw |runback dh1:ansi/ladraw.101 ;BUTTON05: UserEdit |run >NIL: bbs:utils/UserEditor ;NUTTON01: Utility |runback dh1:ansi/ladraw.101 ; "KEEPA-YA-PAW-OFF" FILES I WON'T LET YOU D/L OR VIEW" ; RESTRICT S:ACP.STARTUP ;***RESTRICT*** Prohibits a RESTRICT BBS:user.data ;user frp, D/Ling any of RESTRICT BBS:user.keys ;the listed files NO MATTER RESTRICT BBS:NODE0/UDLOG ;his ACCESS LEVEL. This RESTRICT BBS:Commands/BBS.CMD ;command was added for RESTRICT BBS:Commands/SYS.CMD ;"SECURITY REASONS" against RESTRICT S:bbs.startup ;would-be 'hackers' RESTRICT S:user-startup RESTRICT S:user-startup2 RESTRICT S:startup-sequence RESTRICT BBS:config0 RESTRICT BBS:config1 ; ; ; =========END OF SAMPLE ACP.STARTUP=========== ; 4. "Explanation" of ACP.STARTUP Obviously ACP.STARTUP is a rather complex creature to setup from scratch. This is why we go into such detailed explanation, and why all S!X Modular Install Packages will contain a generic setup which should work (with minor modifications) for most SysOPS. Nevertheless, let me explain in detail how to set up ACP.STARTUP "from scratch", so that as you gain experience you can alter yours easily to change, update, or modify your system's operations. 1. NODE* vs NODE0 - "*" is the familiar WILDCARD (*) and means ALL NODES. If you want to do different things on each node (Look at example again) then you must give specific commands to each of your NODE(s) what they are to do. 2. **ALL COMMANDS** - must begin on COL(1) or you must use the ";" to DISABLE. Notice I chose to say DISABLE vs "Comment Out"....this is to remind you about the ***CAVEAT*** for inserting comments anywhere in the ACP.STARTUP. However the ";" in COL(1) is not considered a "comment"; rather we consider it a "Disable Feature". a. "Variable Value Commands" ie: NODE* LEFTEDGE 0 ^ ^ ^ ^ | | | ----- assign "value" 0 to LEFTEDGE | | ---------------variable "labelname"=LEFTEDGE | -----------------*ALL** nodes -------------------- NODE command 1. **ALL** "Node" commands may be placed anywhere in the text file after NUMBER_OF_NODES specification. 5. CHAPTER 5 Detailed Explanation of Each ACP.STARTUP Parameter =============================================================== *************************************************************** CHAPTER 5 Detailed Explanation of Each ACP.STARTUP Parameter *************************************************************** Please refer to CHAPTER 4, sample ACP.STARTUP. The explanations given are in the same sequence as appears in the example. 1. For those wishing to use the GUI CONFIG(x) initialization system, CHAPTER 5 explanations of the parameters are identical as to each's function. Refer to CHAPTER 6 for setup. ******************************************************* ACP.STARTUP PARAMETERS "Individual Command Explanation" ******************************************************* ----------------------------------------------------------------- ACP_PRIORITY x Sets the Taskpriority of ACP.CTRL to 'x' ----------------------------------------------------------------- ITOP 23 ILEFT 220 Sets the Window to the specified Coordinates. ----------------------------------------------------------------- NUMBER_OF_NODES 3 Tells ACP how many nodes you are running? **NOTE**: 'NODE' commands must not be used before specifiing this parameter. Otherwise you are talking about "Node(s) and ACP has no idea what you are saying as you have not informed it "How Many of Them". ----------------------------------------------------------------- NODE* LEFTEDGE 0 Speficies Node(x) left position of S!X window. NODE* TOPEDGE 0 Specifies top position of the S!X window. NODE* WIDTH 640 Specifies the width of the S!X window. NODE* HEIGHT 200 Specifies the length of the S!X window. NODE* BITPLANES 3 Specifies the number of bitplanes you wish. Values can range from 0 to 4. This tells S!X how many colors are allowed for this Node(x). BITPLANE 0 = Use WorkBench Screen and colors associated with it. 1 = 2 colors 2 = 4 colors 3 = 8 colors 4 = 16 colors You can give "different values" to several nodes, providing your system has such capabilities. I ofter run my "Local" in 724 x 565 HiResPAL, but use 640 x 256 for "Phone" node on a A2000 NTSC Video II VGA Card machine. Some swear that BITPLANE 1 makes file transfers faster with some terminals. ----------------------------------------------------------------- NODE* ACTIVATE_WINDOW If this command is given, the specified node will be started directly with a opened window. ----------------------------------------------------------------- NODE* IDLENODE This command tells ACP not to load the specified node. ----------------------------------------------------------------- NODE* ICONIFY If Set, the BBS will start all nodes Iconfied. **NOTE** This must be the LAST COMMAND in the sequence of all "Window Specifications" for your Node(s) and ACP if you wish BOTH to start in the "Iconified State ----------------------------------------------------------------- STARTNODE0: bbs:express [>NIL:] 0 STARTNODE1: bbs:express 1 STARTNODE2: bbs:express 2 These commands specify which nodes should be started. *NOTE* that most should use the "Optional" >NIL: in the command due to S!X normally from "startup(s)" on each WARM/COLD boot. Startnode(x) command replaces several scripts which were required with former /X and S!X versions. ----------------------------------------------------------------- NODE1 TRAPDOOR This is a **SPECIAL STARTUP COMMAND** requiring the external TrapDoor software. The command tells ACP to use TrapDoor to start each Node() in question. If ths option is used TrapDoor must start S!X with the following command values: S!X <node-number> <baudrate> ----------------------------------------------------------------- LOADCONFIG ***OLD ALTERNATE WAY OF STARTING BBS** This is the former /X and S!X way of loading almost 90%+ of the data now contained within ACP.STARTUP. 1. CONFIG was an "Executable" that generated Config(#) binary-coded files for each Node(#). It used a very "user-friendly GUI interface; each Config(x) was 1972 bytes. 2. ****STILL WORKS**** You can still use CONFIG and CONFIG(x). As a matter of fact a great number of "Doors" and S!X Utils still get their information from Config(x) files.......therefore you should retain CONFIG and CONFIG(x) binaries and update them often. ***CAVEAT*** You must be 100% certain the information in your ACP.STARTUP is correct to your Config(x) files, in order to start either way or be certain that "Doors" will run correctly. 3. A further explanation of CONFIG and CONFIG(X) can be found in CHAPTER 6. ----------------------------------------------------------------- PUBLICSCREEN AEBench This lets you specify "PublicScreen" for ACP to run on. If the screen is not found, it will be created. If this option is not used, ACP will use "WorkBench" screen. ***CAVEAT** Above is not 100% true. If you run special programs (NTSC2PAL), a "Video Card", or DOS3.0+, there are several new graphic promotion modes. Check you DOS manual regarding PUBLIC, CUSTOM, "SHANGHAI" if confused on this. ----------------------------------------------------------------- NODE* INTERLACE ***CAUTION*** This is probably already specified in your PREFS:, "Startups", or other CustomCommands on your system, especially DOS3.0+ with PUBLIC/CUSTOM/SHANGHAI. The command tells ACP to start the Node(x) in INTERLACE if specified, but must be compatable with your machine's screen capabilities. ----------------------------------------------------------------- NODE* BBS_LOCATION <Path> You ***MUST ASSIGN*** BBS: somewhere during your "startups" before attempting to load ACP. Otherwise all "Doors" and other commands looking for BBS: will fail........ This entry just tells ACP to go find that ASSIGN and use it, i.e. ASSIGN BBS: DH0:BBS would be in your "startups". ----------------------------------------------------------------- NODE* USERDATA_LOCATION BBS:User.Data NODE* USERKEY_LOCATION BBS:User.Keys These ***SHOULD*** be in the ROOT DIR of BBS: Although you can put them elsewhere, almost all "Doors" and other utils WILL FAIL, as common practice has defined their location to here since Mike Thomas's V0.9 releases. "Hackers" can try to get your DATA or CHANGE IT. This is why RESTRICT, ACCESS LEVELS, and LOGOFF BATCHES were added to S!X to make "backups" in case of such an attack. --------------------------------------------------------------- NODE* TEXT_PATH <PATH> You ****MUST*** specify this entry. It is possible to move your BBSTexts to some other <path>, such as RAM:, for increased speed. In this case it would look for RAM:BBSTexts/logon.txt for your logon.txt 1. <PATH> assumes you are using a different DEVICE: instead of the normal BBS: (which is almost always itself and assign) such as the normal ASSIGN BBS: DH0:BBS 2. DO NOT specify with this new command: Right---> NODE* TEXT_PATH RAM: Wrong---> NODE* TEXT_PATH RAM:BBSTexts -------------------------------------------------------------- NODE* NEW_USER_PASSWORD <NewPass> Most SysOPS will probably ";" DISABLE this command. If set any "NewUser" must know this PASSWORD, or he will be unable to logon to your system. Unlike InterNET, S!X does not allow for 'Anonymous' or 'Guest' connections, so consider whether you want to block out all new callers. ----------------------------------------------------------------- NODE* SYSTEM_PASSWORD <Yes> In this example, the actual PASSWORD="Yes" as a string. With any /X or S!X above V2.0 you have the ability for PRIVATE.TXT which is normally a "Disclaimer Screen" to make sure people know your rules and the SYSTEM PASSWORD is shown.....if they don't agree by saying "Yes", they cannot logon your system. Used without PRIVATE.TXT or the PASSWORD being displayed, this keeps your system PRIVATE to only those knowing the PASSWORD gaining entry into the system. ----------------------------------------------------------------- NODE* BBS_NAME Doc's House, S!X Development Team This is a <string> of your system's name which will be shown to callers upon logon. It is also used by various "Door" commands to get your system's name to add to files or other functions. ----------------------------------------------------------------- NODE* SYSOP_NAME Doc This ***MUST BE*** the name as it appears in USER.DATA SLOT(1)!!! It is used extensively in screen displays, "chat", "Doors", and SYSOP functions. ----------------------------------------------------------------- NODE* GEOGRAPHIC_LOCATION Columbus,OH This <string> tells callers where your system physically is located, such as Miami, Frankfurt, London, or Hawaii. ----------------------------------------------------------------- NODE* SHUTDOWN_BATCH S:CloseMeDown This is a "Script" which will be executed should you shutdown a NODE(x). Its primary use is saving important data, doing system/bulletin updates, and for safety in case of a "soft system failure" before "Auto-Rebooting" your machine. ("S" flags need not be set on scripts run from ACP.STARTUP) This command is very similar to LOGOFFBATCH, so read that for some special information (especially #2). ----------------------------------------------------------------- NODE* LOGOFFBATCH S:upscript This is one of the most commonly used S!X features. Each time a caller logs off, you can execute this script updating bulletins, doing "backups" of critical data, testing files, or running any commands which are executable via standard Amiga "script" language. 1. **NOTE** You do not have to set the "S" flag; S!X is intelligent and knows to execute this file. However if you run S:upscript as some folks intermittently from a CLI/SHELL, either use the "execute" command or set the "S" flag. 2. ***CAUTION*** There are some "hybird" CLI/SHELLS out there. If your LOGOFFBATCH does not work, then set the "S" flag. ----------------------------------------------------------------- NODE0 PLAYPEN bbs:Node0/playpen NODE1 PLAYPEN VD0:playpen NODE2 PLAYPEN dh2:source/playpen You'll note that newer versions of S!X can now use any valid path for PLAYPEN; it does not have to be in the BBS:Node(x)/PLAYPEN. However you must "plan" your path. If you have a **LOT** of ram (I really suggest "dynamic recoverable such as VD0: RAD:) then you can save HD read/writes by doing U/L direct to RAM space. Use this with caution; someone may make a large batch upload of 5-10 megs and I guarentee you will have a spectacular crash running out of memory. ----------------------------------------------------------------- NODE* FilesNotAllowed BBS:FilesNotAllowed This command prevents the uploading of certain files to your S!X BBS. You create a standard ASCII text file containing the names of all files you wish to prevent from being UPLOADED. 1. You can use WILDCARDS, but **PLEASE TEST** as CLI/SHELLS vary. For safety use the old style "#?". EXAMPLE ----- Sample BBS:FilesNotAllowed ----- #?.arc #?.nfo #?.pak ----- cut here ----------------------------- 2. The "UPLOADING" of any file with the above "extensions" is not allowed. Now the uploading of file with these extensions is not allowed. The BBS will skip the upload if it found a file like the above. ---------------------------------------------------------------- NODE* ICONIFY This command starts a NODE() in the iconified state where hitting the Node() on ACP will make the screen active. 1. ***SPECIAL TRICK*** If you have this as the LAST COMMAND (it must be LAST) in your initial ACP and BBS definitions (SEE THE EXAMPLE), then you can start BOTH: ACP and NODE(s) "iconified" which is the way I like starting my system. ----------------------------------------------------------------- NODE* A2232_PATCH This command will tells S!X that you own a A2232 MultiSerial Card. If you do not, please do not choose this option. 1. This option will allow S!X to accept ASCII sends. ----------------------------------------------------------------- NODE0 UNIT 0 NODE1 UNIT 1 This command will tell AmiExpress the Unit of the "device" which you are using on a specifid node. **NOTE** that all nodes may not use SERIAL PORT, nor may they use the common serial.device. So use the UNIT for whatever device you are using and read parameters: DEVICE_DRIVER INIT_BAUD ----------------------------------------------------------------- NODE0 DEVICE_DRIVER serial.device NODE1 DEVICE_DRIVER NODE2 DEVICE_DRIVER baudbanding.device NODE3 DEVICE_DRIVER Gvpio.devices As you can see, many devices are used besides serial.device to your SERIAL PORT. If you have an I/O card, you will likely want to use that device. 1. NOTE that Node(1) has no driver; in our example it is the "Local" and therefore needs no driver. ----------------------------------------------------------------- NODE0 MODEM_OFFHOOK ATM0H1 This command allows you to specify which modem commands to send to make the modem go offhook. Default is ATM0H1 1. This is "Unused" for your LOCAL NODE!! ----------------------------------------------------------------- NODE8 MODEM_INIT ATE0X1S2=255S7=60S27=0S14=1 NODE9 MODEM_INIT ATE0F1M0Q0V1X1S0=0S2=255S7=40S12=255 This command let you choose you modem's settings when S!X is initialized. These strings vary greatly depending on the MODEM and any special I/O cards or DEVICE you may use. 1. Check with your modem's manual for the best parameters. 2. If you have a high-speed modem PLUS any I/O card, you must consider both MODEM and I/O abilities in choosing the best initialization. Call a S!X Support Site for specific help if you can not resolve your problems. ----------------------------------------------------------------- NODE0 TASK_PRIORITY 10 NODE1 TASK_PRIORITY 3 This Oprion lets you choose the Taskpriority by which each Node() will run. There are several considerations, and I will merely outline the "General Rules": 1. Faster Machines- can generally use lower priorities due to faster operations and needing less CPU time 2. "Local Nodes" - general have lower priorities than any "Phone" Node(s) 3. I/O HD CPU - the faster your equipment or enhanced additions.....the lower you can set priorities and yet have MAX CPS RATES. ***NOTE*** You must set ACP at a higher priority than any Node(x) you might be running (SEE: ACP_PRIORITY). ----------------------------------------------------------------- NODE0 INIT_BAUD 38400 NODE1 INIT_BAUD 76800 This **IS NOT** baudrate between two modems!!! It is the data rate between your MODEM and your COMPUTER. It will vary: 1. 19200 is MAX for normal Amigas. 2. 38400 is MAX using the special BaudBandit.Device 3. 76800 is MAX you should use for a "Local" and an A2000-3000 machine For other machines having I/O cards or special enhancements you can achieve much faster rates. "Local" and therefore needs no driver. ----------------------------------------------------------------- NODE0 SERIAL_BUFFER_SIZE 4096 This is the "STACKsize" which this NODE() will use in transferring data. This parameter will vary between Amiga computers by MODEL, CPU/FPU SPEED, MODEM, and other parameters in achieving highest speed performance. 1. Please consult your modem manual, DOS Manual, and a S!X Support Site for current "best known values" we have for your particular configuration. Sorry....realize ***NOW*** that many things in computing are still based on experience, especially with such variations in HARDWARE, OS, and SOFTWARE. ----------------------------------------------------------------- NODE0 MODEM_RESET ATH0 NODE2 MODEM_RESET ATM0H0 This command sets your modem reset command if a user logged off the system and the modem began to reset itself. 1. Some may prefer not using M0, as they like hearing their modem work and knowing "Phone Lines" are working. ----------------------------------------------------------------- NODE* MODEM_RING RING Command indicates what <string> will be sent by the modem when a user calls your system. RING will show to indicate an incoming call to S!X has been detected. ----------------------------------------------------------------- NODE* MODEM_ANSWER ATA? This <string> is "standard" on all modems. It is the command that is executes when the modem detects RING. It therefore causes the modem to be answered AUTOMATICALLY. 1. If your S!X does not answer...not having this parameter passed correctly is usually a "common cause". ----------------------------------------------------------------- NODE* MODEM_HARDFLUSH This is a **SPECIAL** command, helping those who may have some problems with hanging up the modem correctly. 1. Using "HardFlush" causes S!X to drop DTR 2 times. ----------------------------------------------------------------- NODE* TRUE_RESET This will reset the Modem with a TRUE DTR "Hangup. Later it will be intialized the modem with MODEM_INIT. Using this command will take several seconds in "Hangup/Reset" time. ----------------------------------------------------------------- NODE* CONNECT_300 CONNECT NODE* CONNECT_1200 CONNECT 1200 NODE* CONNECT_2400 CONNECT 2400 NODE* CONNECT_4800 CONNECT 4800 NODE* CONNECT_9600 CONNECT 9600 NODE* CONNECT_14400 CONNECT 14400 NODE* CONNECT_16800 CONNECT 16800 NODE* CONNECT_19200 CONNECT 19200 During connection sequence, the connect rate <string> is sent to S!X, You must specify these "Connect Strings> for each desired rate of connection. 1. You must be sure in MODEM_INIT that your modem can "echo" or "return" these values to S!X. Modern HSpeed modems have other <strings> which S!X users, so check that your modem can work at full capacity with S!X. ----------------------------------------------------------------- NODE0 CONF_NAME 01-NewApps NODE0 CONF_NAME 02-Amiga NODE2 CONF_NAME 01-Demographics NODE2 CONF_NAME 02-SalesTrends This is what you have named CONF(1) on your system. Whatever <string> appears after the "-" will be the name by which this conference is known to S!X 1. ***NOTE*** It is "practical" to run several, different appearing S!X systems within one central S!X. This can be done by having different CONFERENCES for different NODE(s). a. EXAMPLE: ONE "phone line" could answer displaying an "AmigaBBS", whereas a SECOND "phone" might answer with completely different CONFERENCES. b. To do this practically, members need different "NAME" on each NODE(x) and you must create different MENUS, BULLETINS, TEXTS, ETC for each node. 2. I ***REALLY DO THIS***!! I have one S!X node for a normal BBS; the other node is completely different and strictly for BUSINESS CLIENTS.....so they obviously look very different from each other. ----------------------------------------------------------------- NODE0 CONF_LOCAL 01-NewApps/ NODE0 CONF_LOCAL 02-Amiga/ NODE2 CONF_LOCAL 01-BBS:Demograph/ NODE2 CONF_LOCAL 02-BBS:Trends/ This parameter works with "CONF_NAME", and specified a physical location (DIR or directory) for files to exist within that conference. Within each conference are other Sub-Directories for MAIL, UPLOADS, and other functions. ----------------------------------------------------------------- NODE* TOTAL_CONFERENCES 9 TOTAL CONFERENCES ***MUST MATCH** the specifications you tell S!X in CONF_NAMES and CONF_LOCAL. Failing to do so accurately, S!X either not display or use all your conferences, or become "paranoid" trying to find CONFERENCES which do not exist. 1. Recheck your entries carefully......this is a major error source in configuration and operations, especially if you run "Multi-Boards" as described in CONF_NAME. ----------------------------------------------------------------- NODE* EALL_LEVEL 200 This parameter lets you choose the level at which a User can send a message to EALL (ALL) users. ----------------------------------------------------------------- NODE* QUIET_NODE 200 (V0.39i) This recent addition to S!X allows members to use the "Q" command upon Logon, thereby "quieting" the Node(x). It also will hide the member from having S!X's "Who" door detail their presence or activities on the S!X system. ----------------------------------------------------------------- NODE* WHO FILENAMES 200 (V0.39i Lets you define a User Level where the Uploaded/Downloaded Files are either shown or hidden in the WHO Command. **NOTE** Only with the "internal" S!X WHO Command at this time. A S!X Door Command for S!X Door Coders can be used to incorporate this feature. ----------------------------------------------------------------- NODE* ACCOUNT_EDITING 255 Be aware this is a ****CRITICAL SECURITY COMMAND**** which allows access to S!X Account Editing of user accounts. It is highly reccommended that ACCESS LEVEL=255 and given only to extremely trusted persons. Accounts can be DELETED, PASSWORDS OBTAINED, and security destroyed or compromised be giving this access carelessly. ----------------------------------------------------------------- NODE* BULLETINS 3 This defines the ACCESS LEVEL needed to view bulletins on your S!X, usually it is set low. 1. Do not get confused between the bull##.txt which are usually in BBS:Bulletins/ or BBS:Conf(x)/Bulletins and those used to display messages such as bull200.txt. a. These are normally a "DIR" you keep with several sequentially numbered bulletins describing the operation of your S!X, special bulletins about fastest transfers, most activity, accepted archive methods, or perhaps various modem setup strings. b. The later are usually in the root of BBS:Conf(x) and use the "###" number to specific ACCESS LEVEL needed to view a special bulletin based on S!X AccessLevel. ----------------------------------------------------------------- NODE* COMMENT_TO_SYSOP 5 Another command which is normally set quite low, OFTEN below access needed to "Write" mail to others. It defines the access needed to use the "C" command (Comment to SysOP). 1. We normally set "low" so even new applicants can leave private mail to SysOP, but cannot post messages to others until their account has been approved by SysOP. ----------------------------------------------------------------- NODE* DOWNLOAD 10 With this command, you tell S!X the access needed to D/L a file from any of your BBS:Conf/Paths that may be listed in BBS:conf/dir(x). 1. Many make the DOWNLOAD access higher than UPLOAD so new applicants can UPLOAD but not DOWNLOAD until approved, but most use the same level. The reason for different levels, is so you can see the quality of files a potential new member might be sending to your S!X system. ----------------------------------------------------------------- NODE* ENTER_MESSAGE 10 At this level a member can leave messages to ALL (*NOT EALL*) and either PUBLIC or PRIVATE mail to other members of your system. This level defines the access needed to acquite "normal E-Mail" privledges on your system. ----------------------------------------------------------------- NODE* FILE_LISTINGS 10 Viewing of "Dir(x)" files is controlled by this parameter. 1. I have seen a few S!X boards which make this lower than DOWNLOAD so folks can see but not get files either to "entice more activity" or as advertising their files. 2. A very few make this higher than DOWNLOAD, usually as either a "punishment" for bad behavior or to restrict a member from seeing their entire Dir(x) lists on some PRIVATE systems. For the vast majority: DOWNLOAD, UPLOAD, FILE_LISTINGS should all be the same level to avoid members reporting to you that the system has "bugs". ----------------------------------------------------------------- NODE* JOIN_CONFERENCE 10 Defines access needed to use the "J" command, switching between different S!X Conferences. 1. This only defines the "J" command!! ACCOUNT EDITING defines to which Conf(s) a member has access. a. Defining your "J" level incorrectly can cause some annoying "bugs", such as a member having access to several Conf(s) but being unable to use them as the "J" command is not active. ----------------------------------------------------------------- NODE* NEW_FILES_SINCE 10 One of the most "used" commands on S!X is the "N" command to see "New Files" since last called. With many modern "Doors", you can see files REVERSE, MINUS a given number of days, only new in "specific" Dir(s), and many other options. It is probably the most used command in S!X. 1. There are multiple "N" doors and many parameters. Commands are CLI/SHELL stackable with such options as N S U, N S A, N -10 A, and several other commands. (You should provide a ^N "help" file for all the) ( varieties of "N" you offer your members.) 2. ***CAVEAT*** "The ARCHIVE Dir(x) Trick)" Many of you will want to maintain an "Online Archive Listing" of all your offline files. If you do so, there are some special tricks you need to know if you do not follow S!X format exactly. This has to do with how S!X scans under the "N" command for such things as COL(1)=space, COL(16-22)=date, "-""-""-" text in a file. a. "Doc" maintains such a large archive listing and will send you a sample, or if I get enough requests will write all the "Tricks" in the S!X manual for custom formatted "ONLINE ARCHIVE LISTINGS". ----------------------------------------------------------------- NODE* PAGE_SYSOP 10 This command defines the level needed to page the SysOP under "normal" circumstances [SEE: OVERRIDE_CHAT]. Usage requires that the SysOP has set S!X to indicate he/she is available for "chatting", if unavailable the user is prompted to leave E-Mail via "C". 1. There are (2) theories in using PAGE_SYSOP. Some SysOPS set this value high only allowing established member to page them; they do not want to be constantly bothered by every user constantly paging for unimportant reasons. 2. Other SysOPS keep this low to "encourage system use". They allow all the "chats" to generate interest in their system and help newer members. ----------------------------------------------------------------- NODE* READ_MSG 3 This command defines when a member can read HIS OWN private mail, meaning mail addressed to his account, or he can read any mail written "Public" to/from other members. 1. This is "normal" E-Mail status for S!X. He can not read another member's PRIVATE MAIL, MAIL TO SYSOP which is not "Public", or other items in the MsgBases. ----------------------------------------------------------------- NODE* REMOTE_SHELL 255 This option defines the level needed to use "Remote Shell", which is access to your system's DOS via CLI/SHELL. This command ***VARIES GREATLY*** in different S!X revisions and according to how you SysOP has defined many parameters for security reasons. 1. Many SysOPS use special "Doors" for CLI/SHELL have robust protections against "hackers", i.e. Falcon's V3.5 SHELL. As such BBS:COMMANDS/BBS.CMD may actually control some of these "Remote Shell" functions. In any case, this is a ****CRITICAL SECURITY COMMAND****. You will be granting someone the ability to enter your system's DOS, thereby granting use to DELETE, FORMAT, or other commands (depending on how robust the "shell" may be). Therefore it should be HIGHLY RESTRICTED to LEVEL=255. ----------------------------------------------------------------- NODE* DISPLAY_USER_STATS 3 This controls the "S" command in S!X. S!X will display a complete "statistics" of any member's account including UPLOADS, DOWNLOADS, DAILY TIME LIMIT, and other parameters. We suggest keeping this value low, as everyone should know their activity and "record" on your system. ----------------------------------------------------------------- NODE* UPLOAD 3 This is probably the most important command to the SysOP. It defines when someone can use the UPLOAD "U" command. This should obviously be set quite low; 98% of S!X Systems are for the purpose of exchanging data electronically. If some member really abuses your system uploading very poor programs or data, it is better to use the "DELETE KEY" for that user than punish everyone by restricting uploads. ----------------------------------------------------------------- NODE* VIEW_A_FILE 10 This command controls "V" on S!X, which allows member to view text files within your Dir(x) listings or BBS:CONF(s)/Paths definitions. *NOTE* We are talking about "Uploads" which are of a text or ASCII nature: i.e. .doc .txt .man There are two (2) schools of thinking: 1. Some SysOPs RESTRICT the "V" command, rather making you D/L the file to prevent abuse of the priveledge and stop people from a type of "Free D/L" by using terminal Capture Buffers as well as wasting system time. These are usually the more restrictive PRIVATE type systems. 2. Others allow you to "V" files easily, feeling it is a quick way to pass information to all their members without having to use excessive EALL E-Mail. ----------------------------------------------------------------- NODE* EDIT_USER_INFO 20 NODE* EDIT_USER_NAME 255 NODE* EDIT_USER_LOCATION 255 NODE* EDIT_PHONE_NUMBER 255 NODE* EDIT_PASSWORD 20 The above options are used with S!X "W" command, either the INTERNAL or certain external "Door" commands especially written to be compatable with S!X. **NOTE** there are several other <OPTIONS> available with the "W" command, such as editing # LINES/SCREEN, but these are given to everyone and not controlled by special S!X parameters. The "Main" command defines if a member can alter certain information and operations of his account (EDIT_USER_INFO). 1. Assuming a member has the required access, there are FOUR (4) controlled fields: NAME, LOCATION (address), PHONE NUMBER, and PASSWORD. Normally most SysOPS will *DISABLE* the member's ability to change either NAME, LOCATION, OR PHONE. Otherwise you won't even know who's on your system with name changes, E-Mail will become a total mess, and many people will "hack" false information. 2. PASSWORD should always be granted, except where there is a known **SECURITY PROBLEM**. It is up to your members to change their PW often and guard against willful or unintentional usage of their account by being careless. (USE DIFFERENT PASSWORDS ON EVERY BBS....and do not use "patterns" which could be redily guessed by even a SysOP!!) ----------------------------------------------------------------- NODE* ZIPPY_TEXT_SEARCH 10 Probably the "2nd-3rd Most Used Command" in S!X, excepting "N" and "D" is ZIPPY, or the "Z" command. "Z" can be either an internal command in older revisions, or a customized command in BBS:System (currently Mack Lifeguard TURBO ZIPPY). 1. The member enters a <string> to be searched, and choses either ALL, SPECIFIC DIR(x), or UPLOAD to search for the given string. "Z" searches the entire Dir(x) for matches (meaning FILENAME, DATE, SIZE, DESCRIPTION, or UPLOADER). Advanced versions allow for D/L flagging via WILDCARD, FILE #, or CURSOR selection. 2. "Z" should avoid most duplicate uploads, or finding latest versions if the user checks correctly and the S!X SysOP maintains informative DIR(x) listings. ----------------------------------------------------------------- NODE* OVERRIDE_CHAT 250 This is a "SPECIAL COMMAND" which overrides the SysOP setting whether "Chat" is available or not. Primarily it is intended for other system SysOPS, (normally "Co-SysOPS") to be able to reach the main system operator even when it is not normally convenient. ----------------------------------------------------------------- NODE* CHAT_COLOR_SYSOP 33 NODE* CHAT_COLOR_USER 35 This option requires that the the COLOR_COMMAND "M" be ON by both SysOP and "Member". If either has COLOR=OFF, "chat will still function normally but "Color Queing" will not show. The SysOP's words are shown in one color, whereas Member's comments appear in a different color allowing easier reading of who is saying "what". ----------------------------------------------------------------- NODE* START_0300_TIME 0 NODE* START_1200_TIME 0 NODE* START_2400_TIME 0 NODE* START_9600_TIME 0 NODE* START_19200_TIME 0 NODE* END_0300_TIME 0 NODE* END_1200_TIME 0 NODE* END_2400_TIME 2359 NODE* END_4800_TIME 2359 NODE* END_9600_TIME 2359 NODE* END_19200_TIME 2359 These times are noted in MINUTES beginning at "Midnight"=0 and ending at "11:59PM"=2359. For each BaudRate there is a START and END time, being the times at which callers at these bauds may call your S!X BBS. 1. START and END = 0 Says you do not allow callers at this BaudRate. Normally you will also have a file called NOCALLERSAS<baudrate> to display, although this is a separately controlled feature of S!X. 2. START=0 END=2359 Means callers are allowed at this BaudRate continuously. You may specify any combination, such as only letting 2400 baud from 600 (6AM) to 1200 (NOON), and only allowing 9600 from 600 (6AM) to 1920 (8PM) daily. ----------------------------------------------------------------- NODE* SYSOP_READ 255 "Accounts" which have this ACCESS LEVEL can real all messages within the Conf(s) MsgBases, include other's "PRIVATE MAIL". Therefore, it should be restricted only to LEVEL 255 SysOP, and then the SysOP has a responsibility to respect other people's privacy. The only *VALID* reason for even scanning another's private mail is in considering **SECURITY ISSUES** or possible "abuses" or "improper actions" on the system. ----------------------------------------------------------------- NODE* OVERRIDE_TIMES 200 This is another of the S!X *SPECIAL FEATURES* added for highly specific systems. The command allows a user to logon the system even if START_<baud>_TIME or END_<baud>_TIME would not normally allow access to S!X. This "OPTION" was added because you might have a special member who just does not own a High-Speed modem for the normal baudrates you allow during certain hours, so we suggest you limit usage only to HIGH LEVEL ACCESS USERS. ----------------------------------------------------------------- NODE* KEEP_UPLOAD_CREDIT <opt> This Option lets specify the way upload credits are stored and also how to keep track off additional time awarded for uploads. OPTIONS are "numbers" which are as follows: 0 - Do not keep upload credits. When the user logs off S!X, any additional time they might have used for UPLOADS will be LOST!!! 1 - Keep upload credits and award extra time for ONLY THIS SESSION. If the user logs off then and "extra time credits" will be lost. 2 - Keep upload credits and award extra time to the user's account until 11:59PM. The user may call back anytime during the calendar day, which is Midnight (START_<baud>_TIME = 0) through 11:59PM (END_<baud>_TIME = 2359) and any "extra time" will be credited to his/her account. ----------------------------------------------------------------- ******PLEASE READ ME EXTREMELY CAREFULLY!!!!!!******* This describes using "Presets" for both a basic S!X BBS and the new S!X "Extended Conference System". You must read carefully to understand the differences in setup and in using either 0-9 CONFERENCES or using the new "Greater Than (9) Extended Conferences". NODE* PRESET_ACCESS_LVL 01-10 ^ ^ ^ ^ |__ |__ The Command |_ |_____ the Variable | | | | Node specification identifies which preset (1-6) This group of entries controls ACCOUNT EDITING, the "1" command available to S!X SysOPS. So that you do not have to manually edit many fields, it allows you to have defined "presets" in validating members to different LEVELS, RATIOS, BYTE LIMITS, CONF ACCESS, DAILY TIME USE. Let me show you a sample and then explain different options or "strategies you might use: NODE* PRESET_ACCESS_LVL 01-20 NODE* PRESET_RATIO_TYPE 01-0 NODE* PRESET_RATIO 01-2 NODE* PRESET_DAILY_BYTES 01-200000 NODE* PRESET_CONF_ACCESS 01-X________ ;NODE* PRESET_CONF_ACCESS 01-BADBOYS NODE* PRESET_TIME_LIMIT 01-2800 NODE* PRESET_ACCESS_LVL 02-5 NODE* PRESET_RATIO_TYPE 02-1 NODE* PRESET_RATIO 02-3 NODE* PRESET_DAILY_BYTES 02-500000 NODE* PRESET_CONF_ACCESS 02-XXX______ ;NODE* PRESET_CONF_ACCESS 02-NEWUSERS NODE* PRESET_TIME_LIMIT 02-3600 NODE* PRESET_ACCESS_LVL 03-30 NODE* PRESET_RATIO_TYPE 03-2 NODE* PRESET_RATIO 03-5 NODE* PRESET_DAILY_BYTES 03-1000000 NODE* PRESET_CONF_ACCESS 03-XXXXX____ ;NODE* PRESET_CONF_ACCESS 03-NORMAL NODE* PRESET_TIME_LIMIT 03-4800 1. If you just "scan" the above, you'll not that all the values vary. Rather than describing each (I already did not list "Preset 4-6" to save manual space), let me explain the different options available. ACCESS_LVL - is similar to other S!X commands. This sets the user's ACCESS LEVEL if you chose this preset for the account. RATIO_TYPE - There are (3) variations: "0" - S!X will compute all "ratios" based upon bytes. It compares UPLOAD to DOWNLOAD and ignores the number of files entirely. "1" - This is the **MOST RESTRICTIVE**. It requires meeting BOTH a "Byte" and a "File" RATIO. If you use this, remember that may have a byte ratio of 20:1 but if they U/L large files and D/L small, this method will PROHIBIT D/Ling. "2" - This is the **MOST GENEROUS** and ignores "Bytes" counting only the NUMBER OF FILES. Every file (whether 1K or 1MEG) is of equal weigh; I know of no system which still uses this due to wide-spread abuses by many users. RATIO - this is always a "touchy issue" to both SysOP and users. Ratio is merely the relationship of "one thing" vs "another". NORMALLY most SysOPS use bytes, so a ratio of 3:1 means you can D/L 3MEGS for every 1MEG you upload. "DISABLED" is a ***SPECIAL CONDITION*** 0 - If you set RATIO = 0, you are saying there is "no limits" on this user's U/D activity. It is often referred to in BBSs as a "Freebie" or "Leech" account. DAILY_BYTES - High-Speed modems make the above examples obsolete. A better approach to setting limits is the following formula 1. MAXbaud x TIME_LIMIT = DAILY_BYTES -------------------- .8 We came up with this "formula" based on HST maximum baud rates, and we considered the "Extra Time Credits" a user might earn if doing much uploading to your system. CONF_ACCESS - ***SPECIAL NOTE*** This field relates old style /X and S!X V0.15-V0.39m4 !!! 1. **NOTE** This is the "Original 9 Conf" fields used so long in /X and S!X versions. Here you merely tell S!X which conferences to give access where: X = ACCESS _ = DENY ACCESS 2. You can use either an "X_" pattern as described in CHAPTER 9 for the new "Extended Conferences", or you may use the new "NAME" option. a. I have made a few ";" DISABLED "Name" entries you can refer to in reading CHAPTER 9....don't try to understand these yet, just keep reading the BASIC S!X DOCS!! ***CAVEAT*** PLEASE>>>PLEASE>>>PLEASE read CHAPTER 9 before changing from the basic configuration supplied in "S!X Module Install"!!!!! 3. **YOU MUST BE 100% CERTAIN!!!** in entering the "X_string or "Name" correctly if you use "Extended Conferencing" features of S!X. S!X reads this as a <string>. If you leave spaces, miscount, or make other errors.......YOU CAN EXPECT TO HAVE PROBLEMS WITH S!X OR SECURITY! TIME_LIMIT - This is a DAILY TIME LIMIT in "minutes" allowed to this "preset". You should take into account other parameters of DAILY_BYTES, maximum CPU baudrate, # of members, Total NODE(x), Total System Usage in setting time limits. ----------------------------------------------------------------- NODE* RELATIVE_CONFERENCES If this command is given, S!Xhandles Conf(s) differently. If the "J" is selected, it will only allow a user to see the ACTUAL CONF(s) they can join. They will not know how many CONF(s) exist if used with the ~CL command in JOINCONF.TXT. 1. Using RELATIVE_CONFERENCES "disables CONFERENCE_ACCESS display in the "S" command (Well for S!X's "S"....many of the "S" DOORS may not support RELATIVE_CONFERENCES). ----------------------------------------------------------------- NODE* SENTBY_FILES Giving this command causes S!X to write: Sentby: <username> on a separate line following each file upload. It is best to use Sentby: VS allowing users to add some ANSI "tag". 1. Generally "User TAGS" tend not to be their <S!X SLOTname> and there is far too much "ANSI abuse" of stylist "tags". a. S!X supports ID_DIZ which is why some SysOP turn the option to OFF, knowing their members put various "NameTAGS" on all uploads via the ID_DIZ option. ----------------------------------------------------------------- NODE* DEFAULT_CHAT_ON This "toggles" whether the SysOP is "chatable" to normal users. Some SysOPS turn this option ON for some NODE(s) and OFF for others, using certain NODE(S), i.e. phone lines, for their best members. ----------------------------------------------------------------- NODE* BREAK_CHAT This Command will turn on/off the ability for yar users to break out of the chat by pressing CTRL-C or to stop the displaying fo files with CTRL-C in the chat. ----------------------------------------------------------------- NODE* CLEAR_SCREEN_MSG Causes S!X to send a "CLS" command, or Clear Display Screen, between each displayed message. 1. **NOTE** This command may override any individual users screen settings in "W" parameters. ----------------------------------------------------------------- NODE* ALLOW_FREE_RESUMING You most likely will want this option ENABLED. It allows S!X users to resume any unfinished UPLOADS due to such factors as "Carrier Loss", "Noise", and other conditions. 1. S!X uses special file handling and DIRS, known as the LCFiles and PartUpload "dirs" with this function. Be sure you have these "dirs" in each of your S!X Conf(s). ----------------------------------------------------------------- NODE* DO_CALLERSLOG S!X Callerslogs are a very complete description of almost every action a user may take from joining a conference to using a door. Callerslog(s) also show all U/Ds, CPS, and are a record of what each caller did including many ERRORS in S!X operations. Many, many of the S!X "Doors" you may consider using requires generating Callerslog(s), as they gain the needed information from your logs. We HIGHLY SUGGEST using both "Callerslog" and "UDlog" for your S!X, as almost all the advanced "Doors" and other advanced features will need access to these log files, but you need not maintain "logs" for your LOCAL (maintenance) node. ----------------------------------------------------------------- NODE* DO_U/D_LOG This is a "cut-down" version of Callerslog, showing merely a capsulizeddigest of all U/D activity on your system. Many doors prefer UDlog as it is compact and much quicker than Callerslog for such Doors as "Last 10 Uploads". ----------------------------------------------------------------- NODE* STARTLOG This is a S!X "Debugger" option. "ON" this option generates a file called Startuplg showing all actions of the specified node during initialization. 1. **SUGGEST** you set this option to "ON" during your initial set-up of S!X, and subsequently any time you make significant changes in ACP.STARTUP to verify everything is operating correct. ----------------------------------------------------------------- NODE* DOORLOG This "switch" generates a complete log of all actions on your system which occured as a result of using any "DOORS". It is useful for testing new "Doors" as a DEBUGGER, and also for monitoring usage by your system's members ----------------------------------------------------------------- NODE* SCREEN_TO_FRONT This "toggle" turns on/off the "Jump Screen To Front Logon" feature of S!X. If ON S!X will immediately make the Node(x) screen the "frontmost" when a user logs onto your system, and can also sound a BEEP if you have either the "Setbeep" or similar command (or DOS3.1 you can use the SOUND commodity). 1. NOTE: If you start your screens "iconified", this option will not be "active" for the screen, although the BEEP or SOUND option will still work. ----------------------------------------------------------------- NODE* STATBAR If specified, the NODE(x) will start with a 2-LINE STATUS BAR displaying the "User's Info" to the S!X SysOP. This will show most of the essential data of the "1" ACCOUNT EDITOR. 1. "ON" does cause the SysOP to lose 2 lines of his screen display. So if both SysOP/USER have the same settings for "NUMBER_SCREEN_LINES", the SysOP will be unable to see the 1st 2 lines of of each screen. "HELP" TOGGLE Hitting the HELP KEY will 'toggle' the STATBAR on/off. NOTE: Older /X and S!X versions used the mouse, this has been updated and "mousing" no longer works. ----------------------------------------------------------------- NODE* DIR_IN_KBYTE This feature was added at my suggestion. ZModem is very stable, and most files now exceed 50-80K, so having exact sizes is not as important as several years ago with XModem. 1. This also allows for "D/L by #" to be implemented in S!X easily, and several alternate "Doors" also support or use the KBYTE size display method. ----------------------------------------------------------------- NODE* NO_TIMEOUT This option will disabled and NODE(x) timeout routines. 1. This may be useful for direct line communications or quite useful for "Local" maintenance nodes. 2. ***CAVEAT*** You SHOULD NOT USE this option on any of your active "PhoneLine" nodes. A caller could tie your system indefinitely by just doing nothing, by losing carrier, or many other means which would totally stop all S!X internal checking routines to reset S!X in case of inactivity or other integrity checks. ----------------------------------------------------------------- NODE* SUPPRESS_QLOGON Normally, users have an option of hitting "Q" on logon to avoid seeing your LOGON.TXT and any files you might have associated within it via ~MCI commands. If this command is specified, users CAN NOT bypass either your LOGON or LOGOFF screens, forcing them to see what the SysOP feels is important information about his S!X BBS. ----------------------------------------------------------------- NODE* STEALTH_MODE This command has been changed several times. Currently if ON, it will only display the S!X © and Version and not display any further information until the SYSTEM_PASSWORD is correctly entered. 1. **EXCEPTION** If you have a file called PRIVATE.TXT in BBSTEXTS, this file will always be displayed first. We did this so folks could use PRIVATE.TXT as a "Disclaimer" and actually show the SYSTEM_PASSWORD. If a caller fails (or "REFUSES") to enter acceptance of your system's rules then nothing else is displayed and S!X resets after 3 PassWord fails. Normally most "Disclaimers" will ask for "YES" or "ACCEPT"; we have included an example PRIVATE.TXT in S!X Modular Install Packages. ----------------------------------------------------------------- NODE* QUIETNODE This "switch" activates a ***SPECIAL PARAMETER** in your personal "W" parameter settings to operate. Field "C" in "W" allows you to block the ability of other users to see your presence or report your activities in S!X's "Who" program from other Node() users. 1. NO = Do not "block" YES = "Hide" me from other users. 2. Other "Who Doors" written independently, may or may not support QUIETNODE as they must be properly coded to determine how you have set your "W" parameters. ----------------------------------------------------------------- NODE* CAPITOLS_IN_FILE This option causes all uploaded "FILENAMES" in your Conf Dir(s) to be converted to UPPERCASE. Some SysOPS prefer this to avoid "mixed-case" filenames. 1. Their is no equivalent "command option" to convert all filename entries to lowercase. ----------------------------------------------------------------- NODE* NO_MCI_MESSAGE Turns off all ~MCI, Macro Command Interpreter, function in S!X. These are command your SysOP and certain "Doors" use for special functions. ----------------------------------------------------------------- NODE* NO_WILDCARDS This is probably a command which would make the SysOP VERY UNPOPULAR with his users. If activated, it DISABLES are "Wildcard" (*) features of S!X downloading. ----------------------------------------------------------------- NODE* CONFERENCE_ACCOUNTING This new feature turns on RELATIVE CONFERENCE ACCOUNTING. A better explanation is that your USERS will have whatever RATIOS you've set in EACH CONF() instead of on your entire BBS and all CONF() as a whole. In other words if you use BYTES and set the ratio to 3:1, they must maintain that ratio in each Conf() where they have access. The rational for this feature is stopping "Abuses". Only those which support a Conf() can DOWNLOAD from that Conf(). ***CAVEAT*** The "negative" is that you could have users which genuinely support your MAC, PC, or other CONF() but not say your AmiNET area, but would be precluded from DOWNLOADING due to their bad ratios............so use this with EXTREME CARE. This can be somewhat "Minimized" by putting files which you believe should be accessable from supporting a CONF() in that area and using your Dir() to list them there with the proper BBS:Conf()/Paths allowing for D/Ling from that Conf() ----------------------------------------------------------------- NODE* CENTRAL_HOLD This new feature of S!X eliminates the need for a "HOLD" dir in each of your Conferences. Rather all files which were market "/" or PRIVATE are put into once central area for your review. Some will prefer the old method; others the new "Centralized" option. 1. "ACTIVATING" - You must first create a directory called BBS:HOLD which will receive all the files from every Conf(x) which are "/" PRIVATE. <VERIFY> ***NOTE*** You must create the BBS:HOLD dir or create BBS:Conf(x)/HOLD dirs to store files which were marked PRIVATE, failed your FILECHECK system, or were otherwise meant not to be "Online". 2. ACP.STARTUP - Next you will ACTIVATE the command in your ACP.STARTUP which will cause this feature to become activated. <ERRATA> ***NOTATION*** - The "F H" function will not work with CENTRAL_HOLD as of V0.39n1. This we are aware of and will quickly change the programming of the "F" function to correct withing S!X. However certain previous "3rd Party Door" routines will like not be able to use F H due to the programmers being unaware in advance that this option would be available. ----------------------------------------------------------------- RESTRICT BBS:COMMANDS/BBS.CMD RESTRICT BBS:USER.DATA RESTRICT BBS:USER.KEYS This option restricts members from DLing certain **CRITICAL FILES**. If a user attemped DL, it will write a special message in the "CallersLog" and the DL will be cancelled. ----------------------------------------------------------------- NODE* LOCAL_UL_PATH DH2:Myprojects This allows you to configure the DEFAULT Dir for "Local" uploads, something S!X Development Team members wanted themselves for some time. When you make a "Local UL" S!X will not automatically open on your "Local UL path", using a GUI Requester interface. 1. The requester is "Intelligent" now having buttons for VOLUME and PARENT, so you can switch to other paths if desired. ----------------------------------------------------------------- BUTTON01: PlusED |run BBS:myutils/plusED20 BUTTON02: UserEdit |run >NIL: bbs:utils/MCP NUTTON03: PlusED |run BBS:myutils/plusED20 ^ ^ ^ | | | | Command Name column 24 must contain the '|' symbol | |-BUTTON/NUTTON TO USE BUTTONS - are commands you can add to your ACP yourself and are totally "configurable" via ACP.STARTUP. Normally these are utilities which help you control S!X operations, do maintenance chores, or provide information to the SysOP about S!X's operations NUTTONS - The only difference between a "BUTTON" and "NUTTON" is that you must specify the NODE(x), as NUTTONS are assumed to be commands to manipulate, update, or modify a particular NODE() instead of the S!X environment in general. These are generally commands to edit screens, view CALLERSLOGS on a NODE(s), clean MsgBases, or similar uses. 1. S!X will automatically add the "Node()" to the command string when you click a NUTTON and then a NODE(x). 6. CHAPTER 6 Configuring S!X Using CONFIG and CONFIG(x) Files ============================================================= *************************************************************** CHAPTER 6 Configuring S!X Using CONFIG and CONFIG(x) Files *************************************************************** CONFIG is an executable program. It was written by Mike Thomas and the way all "Original" /X systems were configured using a very "User-Friendly GUI Interface". With the development of ACP.STARTUP scripts (V2.0 - V2.34 /X), Joe Hodge did not update the CONFIG program, but maintained compatability between the old method and the new. S!X also maintained this backward compatabiling due to many "Doors" using Config(x) files and the ease of configuration of a basic system. CONFIG generates "Binary Coded Files", being a mere 1972 bytes which contained all the information needed to start /X or S!X. It is certainly easier to create and "debug" a small 1972 byte binary via a "user-friendly" GUI Interface, than to slave over a 6-8K script of the complex parameters needed under ACP.STARTUP. 1. This is why we have maintained CONFIG, and why we plan of a completely revised S!X CONFIG in the future. 2. Historically ACP.STARTUP was to be only a "Development" interim means to test all the new V2.0 - V2.34 /X enhancements and all the myriad of new features created when Stephan (Steve to his English friends) began development of the S!X system. **************************************************** GENERATING CONFIG(x) FILES USING CONFIG FOR S!X **************************************************** FIRST.....let me say that CHAPTER 6 is after CHAPTER 5 for a reason. I have already given you a very detailed explanation of ACP.STARTUP and explained what each parameter does. There are NO DIFFERENCES between how these parameters operate using CONFIG(x) files and using ACP.STARTUP, excepting that the old CONFIG(x) screens have not been updated and therefore do not contain all the information which ACP.STARTUP does. SECOND....Even though CONFIG is "older" it will work beautifully to configure all the BASIC PARAMETERS needed to run S!X, and pass these parameters to many of the fine existing "DOORS" and S!X UTILITIES which exist. Therefore, I will not give you a "detailed description" of every command within CONFIG as it is GUI and very intuitive once you view the screens. Rather I will explain the difference between using ACP.STARTUP and CONFIG(x) in running S!X and all the utilities developed for /X and S!X. 1. STEP #1 - Find the find BBS:Config. From a CLI/SHELL merely issue the command: RUN CONFIG. a. A screen will open saying: "Ami-Express System Configuration Utility V2.0 Screen 1" b. If you go to the top, you will find a "Pull Down Menu" which will allow you to look at Screen 1, Screen 2, and Screen 3. Take a minute to look at each carefully. 2. STEP #2 - It should be fairly obvious that most basic S!X configuration parameters can be addressed via CONFIG but not **ALL**......especially newer S!X parameters. Nevertheless, we can describe 9 Basic Conferences, all the basic information to control reading files, uploading, downloading, and many other parameters. 3. STEP #3 - Go back and review ACP.STARTUP completely. You'll notice that ACP.STARTUP has individual entries for each NODE(x), or you can use NODE* wildcarding for all nodes. a. CONFIG differs in that it generates a CONFIG(x) file for each node: Config0 Config1 Config2 Each of these files will be 1972 bytes of "Binary Encrypted Data" (ask a programmer friend about coding ULONG VS "Script"). b. Now try to generate CONFIG0 and CONFIG1 files for both your "Phone" and "Local" Node(x) which came in the S!X Modular Installation Package. 4. STEP #4 - ***CAVEAT*** Certainly we can not create 25 Conferences, nor tell Config0 to list Dir(x) in KBytes. This is unimportant. We just want to use CONFIG and CONFIG(x) to make a simple, operational S!X BBS. a. If you look at ACP.STARTUP (either in this manual or that which came in your S!X Modular Install) you will see the disabled entry: ;LOADCONFIG ***LOOK*** for a file S:ACP.STARTUP-LoadConfig which also should come with S!X Modular Install Packages. b. ACP.STARTUP-LoadConfig is the ****ACTUAL*** file I used to start my S!X in testing this module!!!!!! 1. Note that almost EVERY ENTRY has been deleted. This ****DEMONSTRATES**** a simple S!X initialization. 2. YES.....certain of the new commands will not work as I have not defined them. You can add these to the S:ACP.STARTUP-LoadConfig, and then retest for proper operation. 5. To run a "Local Node" remove the device name from the config file and S!X will not use the serial port. To properly remove the serial device, click in the gadget and hit RIGHT-AMIGA-X that will empty the gadget. ****GENERAL NOTES AND CAVEATS**** 1. Obviously doing it via CONFIG, you must know which NODE(x) you are working with. 2. Remember ***OBVIOUS RESTRICTIONS*** such as CONFIG only being able to understand and generate 9 Conferences. You'll have to add CONF(10-whatever) by making additional entries in ACP.STARTUP-LoadConfig 3. ****PROBLEMS**** Please call me "Personally" at Doc's House (614) 855-3114 or leave mail via Internet: gagreen@iwaynet.net Frankly, I'm one of the "last old GeeZERS" to still use CONFIG and CONFIG(x) screens this long with S!X, so I probably can help you much faster with any problem. BTW-----don't panic!!! Config(x) actually is very easy to get running. It takes most reading this manual about 30 minutes any maybe 2-3 tries to have their S!X operational. 7. CHAPTER 7 Installing S!X In Your Startup-Sequences ================================================== ************************************************************* CHAPTER 7 Installing S!X In Your Startup-Sequences ************************************************************* Let me preface this section of the manual, saying there is no "Universal" nor "Perfect Installation Method". Each person's "startups" are similar to the fingerprints or DNA; i.e. no two are exactly alike. Therefore there are limitations to the information herein, and a few of you will experience some minor setbacks due to special utilities, screen modes, or other commands you have running in all your system. Even various shells (C-SHELL, S-SHELL, etc) and 10,000 other commands, patches, and variables come into play. PLEASE DO NOT BE ALARMED! We know from experience that over 90% of you will have S!X running within 1HR from the S!X Modular Installation Packages; over 98% have S!X running within 4HRS without difficulty. 1. S!X Development Team Members are interested in more than just S!X. Many are experienced programmers, testers, or highly experienced experts in general AmigaDOS/OS, so while we can not anticipate "EVERYTHING", we hopefully have anticipated "MOST COMMON THINGS". 1. STEP 1 - Installing S!X and the SYS: Dir Files When you receive a S!X Modular Install Package, or update, you need to copy many files to your SYS: and to dirs which are created within your SYS: Herein we refer to SYS: as that drive which is your "Boot Device". You may call it DH0:, DH1:, or FH2 yet it is still normally a HARD DRIVE from which all your main SYS: directories reside such as LIBS: FONTS: S: L: etcitera. 2. STEP 2 - Altering your "Startups" Whether you use DOS 2.0 or DOS 3.1, the "General Rule" is that S!X is started either by: S:user.startup S:user-startup2 Therefore, let's look at why there are two variations and explain which of you might prefer using one versus the other. I'll start with the "Generic S!X" and explain the *SPECIAL VARIATIONS* later. 3. STEP 3 - Editing the "Startups" ======S:startup-sequence "additions"====== ASSIGN BBS: DH0:BBS ;this assigns BBS: to the HDrive DH0: ;via the Directory created therein ;called BBS ASSIGN DOORS: BBS:DOORS ;"Sequence" of entry is important, as ;BBS: must be assigned first. This is ;where all the "Doors" reside ASSIGN UTILS: BBS:UTILS ;This is where ACP, EXPRESS, and key ;S!X system executables reside PATH BBS: BBS:DOORS BBS:UTILS ADD ;This adds these "paths" to your ;pathstream ;PATH BBS:MYUTILS ADD ;"Optional"...this is so I can keep ;all my S!X maintenance utils in one ;Dir and use from CLI/SHELL or WBench. =====END S:Startup-Sequence===== =====S:User-Startup "Additions"===== run >NIL: ACP ;this actually starts S!X via your ;ACP.STARTUP or CONFIG(x), depending ;on which way you chose to start S!X =====END S:User-Startup===== AS STATED: The above should work for 90%+ of you very "1ST TRY" providing you following the installation directions. 1. FIRST = recheck the "installation" if this is the first time you have installed S!X's basic module 2. SECOND= check that you made the above entries correctly (your SYS: may be DH3:) so do not merely copy the above example. 3. THIRD = ***CHECK YOUR "StartLog". We configured the example ACP.STARTUP and S!X Modules to generate a file when they try to start. Later you can remove this, but we enable it to spot "opppps...I goofed" problems. 4. STEP 4 - "CUSTOMIZED STARTUPS" ***DO NOT PROCEED IF S!X IS STILL NOT WORKING AT ALL*** OK. You now have S!X running, but it may not be exactly correct. Common problems are that the "Screens" are scrolling beyond your screensize, some utils or doors will not work, and other features are behaving erratically. Let me go thru a few of the common "Custom Installations" and perhaps we can clear your problem without having to call a S!X Support Site. a. "Doc's" METHOD - running PAL on NTSC machines in HiRES PAL In the ACP.STARTUP example (in S!X MODULES and this MANUAL) you'll see I set the screens for HiRES PAL, even though I run S!X on a NTSC A2000 G-Force II 40Mh. =====S:Startup-Sequence "Modifications===== ;IPrefs ;REMOVE from startup or that stupid requester ;will drive you crazy and it won't work ;VirusZ ;It starts a "Window" which you **CAN NOT DO** ;before running IPREFS and switching to PAL ;"Any Window Maker" ;Remove any command which opens a window, CLI, ;or display as we have not changed modes yet ; ; ON THE LINE BEFORE LOADWB ADD THE FOLLOWING ;run >NIL: S:user-startup2 ;This will start S!X, convert to PAL, and ;start all "Windowed" type programs after ;we reset IPREFS into PAL. =====END S:startup-sequence "Modifications" =====S:User-Startup2 "Example"===== wait 2 ;timing for IPREFS and AMIGA2PAL setup iprefs ;RESET Screens to PREFERENCES wait 1 ;"timing" thing for iprefs and screens amiga2pal ;Start CUSTOM SCREENS IN PAL ced -r ;CED PRO V3.5--- EATS 182K HOT RALT-RSHIFT-CR run >NIL: ACP ;start S!X ACP and all NODE(S) cd BBS: ;"wake up call" I give it run >NIL: VirusZ ;moved due to "Window Problem" switching to PAL c:runback c:setbeep bbs:myutils/horn3.snd ;HORN on "o" PAGE =====END S:User-Startup2 "Example"===== You will also want to do one of the following: 1. Put the PAL monitor in your SYS:WBstartup and make the appropriate changes to your PREFS: 2. Use the CLI/SHELL utility PAL or PAL-NICO in your S:startup You'll **NOTE** in this entire procedure that I do load CONCLIP in S:startup-sequence and let all the other normal "startups" operate such as ASSIGNS, PATHS.........but I ****DO NOT LET**** any screen open. This is why I create the user-startup2 and put all "screens" there and have it as the last line before LOADWB in my S:startup-sequence. *****YOU MUST**** set the "S" flag on USER.STARTUP2 as it is an "executable script". (I have an ALIAS to set flags RES) b. "Too Few" or "Too Many" ScreenLines. 1. Generally this is a problem caused by either ACP.STARTUP or the differences between NTSC and PAL machines. If you note that you have about 8 lines too few, then you are running NTSC on a PAL machine. 2. If you can not see the "Bottom" lines, you are trying to run a PAL setup on NTSC. In either of these instances, you merely need to load the appropriate Monitor in WBstartup, change your PREFS:, and make a few adaptations to ACP.STARTUP, and possible some commands in your S:"startups". I ***HAVE INCLUDED*** in the S!X Modular Install Package a "C:" Dir. This dir contains Nico Francois's AMIGA2PAL for running PAL Custom Screens on an NTSC as well as the HORN3.SND, RUNBACK, and SETBEEP. If you need PAL or PAL-NICO, these utils should be available on any good S!X BBS (...probably not on /X C-NET or other BBSs HE HE). 5. STEP 5 - I "just can't get ACP or S!X working" a. FIRST....do not "PANIC". We obviously can't anticipate every problem, but we did put quite a bit of "self-diagnostics" into S!X. [SEE TROUBLESHOOTING FOR DETAILED HELP!!] 1. Check your StartLog.....I have it "activated" in all S!X Modular Install Packages, and you will often find the source of error in its diagnostic output 2. **NO ACP** CD to BBS:Utils and enter the command: ACP a. This should generate an **ERROR MESSAGE** likely telling you what is wrong, such as a missing file. 3. **ACP BUT NO S!X** Same as #2 by enter the command: express <node#>, i.e. express 0 a. This should return an ERROR MESSAGE telling you why ACP could not start your S!X Node(). 3. RECHECK your installation if this is a "NEW INSTALL" to be certain you did it correctly 4. RECHECK you ACP.STARTUP and S:"startups" b. ******PANIC!!!!****** Not really!!! Just call a S!X Support Site. We are here to help you isolate such problems. It is possible you made a common mistake, one we didn't anticipate, or found a totally new "bug" we've never seen before. However we will work with you to get S!X up and running flawlessly. 8. CHAPTER 8 - Controlling S!X Via ACP =================================== ************************************************************* CHAPTER 8 - Controlling S!X Via ACP ************************************************************* ACP is the "brain" of S!X. It allows you to control the entire S!X operations on every node(x), get reports on user activities, edit accounts, and run "Custom Commands" via the BUTTON/NUTTON feature. It is important that you understand all of ACP's functions and capabilities. It will make being a SysOP so much easier and enjoyable, and you will find you can be more productive using features we have tested among hundreds of SysOPS as the most useful and productive. Therefore let's go thru a detailed description of ACP and its functions. There should be an "Iconified" window on the WBench (in the lower left corner if you used "Doc's" parameters for HiRes PAL). There are THREE BUTTONS; now just click on the middle one on the right side to enlarge ACP. Let's briefly describe what each "Button" does (SORRY...I am a lousy artist so I won't try to draw a clever ANSI). ***TOP "EDGE" of ACP*** TOP LEFT - **CAUTION** Clicking here (1) time causes all your NODE(s) to become INACTIVE_. If you click (2) times, all NODE(s) become inactive and you quit ACP. 1. The "1" click option is used often to RESET NODE(S) and "2" click to make changes to S!X parameters and then restart with: RUN >NIL: ACP "CREDITS" - 1. Click the RIGHT MOUSE anywhere in the area saying, "S!X Serving Control", or If you use a "HotMouse" anywhere within ACP. You should see a "pull-down-menu": a. PROJECT - will have entries telling you about those working in S!X Development, S!X Support Sites, and other info to contact us for support. b. MASTER CONTROL - this corresponds to the 15 S!X system control commands, and I will explain each later in detail. c. CUSTOM CONTROL - this corresponds to your 15 "Personalized BUTTON/NUTTON" commands which you can make yourself. RIGHT "MID" - This is your "Iconify" button which toggles between display and "Iconified" mode. RIGHT - This is the "Screen Shuffle" which works just like any other window on you WBench. ***TOP "Row" of ACP*** /X - This is what I'll describe as a "Semi Iconify" button. Clicking "toggles" between seeing the entire ACP and just the area where you see the NODE(s) with all your "Custom Commands" and "S!X Current Node Activity" in the iconified state. USER - These are not "Buttons" but show you what is being LOCATION displayed to the right of each Node(x) in the Node(x) ACTION "S!X Current Node ctivity". It shows =Who-n-What= CPS is presently occuring on each Node(x) constantly. ***Node(x) Buttons*** Node(x) - Clicking here if you started a Node(x) in the iconified state will cause that Node(s) screen to become active, and to "Screen Shuffle" to make that Node'(s) screen frontmost. i.e. DeIconify and Screen-to-Front. 1. If already "active", it does only "Screen Shuffle".. ***CONTROLLER & "S!X Recent Activity Display*** <NO_DEF> x - ??? S!X CONTROL - This is a "Toggle" which switches between the 15 S!X CUSTOM COMMANDS and your (15) BUTTON/NUTTONS. "Cycle" - Clicking here will cycle the "S!X Recent Activity Display", showing activities on your S!X BBS as follows: a. LAST (5) CALLERS b. LAST (5) UPLOADS c. LAST (5) DOWNLOADS ***S!X CUSTOM COMMANDS and "BUTTONS/NUTTONS" I will not discuss "BUTTONS/NUTTONS" as these are your customized commands. Suffice to say that clicking the S!X CONTROLLER will "toggle" between S!X CUSTOM COMMANDS and those you create yourself. Now let's go thru all the S!X CUSTOM COMMANDS. This truly is the "Brains" of S!X, so it is imperative you understand what each of these key elements does and represents. ***NOTE*** Darn near forgot....to use any of the S!X CUSTOM COMMANDS you must FIRST "click the command" and then CLICK the "node" you wish the command to act upon. Sorry, but that is pretty important for you to remember!!! [ Sysop Login ].....Logs you into a node as the sysop. It bypasses PRIVATE.TXT, entering your NAME/PASSWORD, PWcheck, "WHO", and LOGON.TXT commands for a normal logon. For this reason it is an "Often Used Feature", saving the SysOP much time logging onto his S!X locally. [ Instant Login ]...This give a carrier detect command to the modem. This is primarily used to re-establish a S!X BBS to a user after talking to them voice on the same line. Knowing this command allows you to "switch" between a MODEM/VOICE call. <ERRATA>......this is SERIOUSLY BROKEN as of V0.39u6. Open on WB in WB colors and position is all DISTORTED. [ AEShell ].........This will open a shell on the Node(x) screen. [ Toggle Chat ].....This toggles the Node's chat request flag. If "Chat"=OFF, only users having access greater than defined in OVERRIDE_CHAT may page the SysOP. [ Exit Node ]......This will shutdown the node in question. ***NOTE*** "Exiting" releases the SERIAL PORT back to the system. It is slightly different than NodeOFFhook, as the phone can now ring or be used for say a terminal program. [ Local Login ].....This is just like logging on "REMOTE", except normally most SysOP only use this on the "LOCAL" (non phoneline Node). It can be used on ANY NODE, and is used to test new screens and features (...especially if you use ~MCI commands). [ Reserve Node ]....This allows S!X to "reserve a Node to only let a specified user logon to S!X. It will display the USER NAME and RESERVED in your ACP's "S!X Current Activity Display" and put a line on your Node(x) AWAITSCREEN.TXT stating that the node is RESERVED with the "UserName". This is a "Toggle"...clicking it again without entering a UserNAME will restore the Node() to normal operation of "Awaiting Caller. If RESERVED, the Node() will return to normal state after the specified caller has logged onto your system on the specified Node(). [ Accounts ]........This takes you into account editing on a node. <NO_DEF> A detailed explanation of "ACCOUNT EDITING" is discussed in CHAPTER 9. [ Init Modem ]......This re-initializes a particular Node(x) initialization string as defined in ACP. program. [ Node(offhook) ]...This will shutdown the node in question and also make the phoneline "BUSY". S!X still maintains control of the SERIAL PORT, so you can not use a terminal or other SERIAL PORT program. [ Quiet Node]......."Quiets" a particular Node(x) so that "WHO" activity and "Q" option on logon is active. <NO_DEF> Is "OVER-RIDDEN" if user has ACCESS_LEVEL above that specified in ACP.STARTUP for these parameters. [ Config Node ].....This will bring up the old CONFIG program for a particular Node(). <ERRATA> **NOTE ME** In CHAPTER 5-6 I discussed starting S!X via both ACP and CONFIG(x), and the importance of maintaining both for many S!X utilities and "Doors". This command uses the same V2.2 CONFIG.EXE that is packed with all [ Node Chat ].......This button takes you immediately into "Chat" on a particular Node(x). [ Config Node ].....This will bring up the old CONFIG program for a particular Node(). <ERRATA> **NOTE ME** In CHAPTER 5-6 I discussed starting S!X via both ACP and CONFIG(x), and the importance of maintaining both for many S!X utilities and "Doors". This command uses the same V2.2 CONFIG.EXE that is packed with all S!X Modular Install Packages. [ Save Win ]........This comand =DOES NOT= require specifing a NODE(x) complement. Rather it merely saves the current ACP window co-ordinates to a file called S:ACP.config. It is used to "place ACP" on your WBench. <NO_DEF> Define new S!X V0.39u+ ScreenModes Operatios [ ScreenMode]....... [ Set NRAMS]........This button will process a pre-configured ASCII <ERRATA>...non-functional file of modem commands that you create and place V0.39m4 in the node directory of each node. NOTE: All of the above mentioned buttons unless said otherwise, require you to press the Appropriate node button for them to take effect. 9. CHAPTER 9 S!X Extended Conferences SETUP ============================================ ************************************************************* CHAPTER 9 S!X "Extended Conferences" SETUP ************************************************************* Starting with S!X V0.39l(x), the number of possible conferences was increased to 25 by popular demand. There will certainly be "REVISIONS" and "CHANGES" as this feature is expanded to either 100 or totally unlimited conferences. Neverthless we wanted to provide a basic explanation of how the new features operated, and how you can set up "Extended Conferences" within S!X. 1. BBS:AreaNAMES - This is a NEW DIRECTORY which you **MUST CREATE** This Directory will hold all the "configurations" files which you will create, (ASCII text files), to allow for using Extended Conferences. You can use any normal text editor to create these. 2. ***SPECIAL NOTES*** NAMING YOUR BBS:AreaNames/<strings> Most of you are familiar with the "X_X_X_XXX" patterns long used by both /X and S!X. In these an X=ACCESS and _=NOACCESS. a. This is no longer ***GUARENTEED TRUE***. You can still use the familiar "X_" patterns if you use (9) or less Conf(s), or you may chose to use the new "Name" pattern available via BBS:AreaNames/<strings>. b. This using "Extended Conferences" ***MUST USE*** the new Directory: BBS:AreaNames/<strings> to configure S!X for these new conferences. However you can still use either the old familiar "X_" pattern or the new "Name" patterns. c. Let me now show you all the various ways you can now configure S!X. *******PLEASE...PLEASE....PLEASE refer to the ACP.STARTUP example in the manual and that came with your "S!X Modular Install Package" in understanding these new concepts to S!X BBS. 3. OLD "X_" PATTERNING of your ACP.STARTUP or BBS:AreaNames/"X_strings" a. If you look in BBS:AreaNames/<strings> you will find some strange looking entries such as a file named "XXX_XXX_X": XXX_XXX_X - YES...this looks amazing similar to what you are used to seeing in your ACP EDITOR, SYSOP "1", or in your ACP.STARTUP file. **CAVEAT** Let me stop much "confusion" immediated, as even I was totally lost over setting this up. The names of the "files" you will be creating have names such as XX______X XXX___XXX XXXXXX___. **FOR NOW** - Please make these names match EXACTLY to the strings you have in your ACP.STARTUP or CONFIG(X) files!!!! Later I will explain how to create up to 256 different "configurations". b. You will be "Editing" these strangly name files. Look at the above example (i.e. XXX_XXX_X) and it's contents are: XXXXXXXXXXXXXXXXXXX_ This is an ASCII "string" of 20 char- aters, and tells S!X which conferences a user who's "P" field you see via ACCOUNT EDITING has access to among all **20 CONFERENCES** using the new "Extended Conferencing System". 1. Yes, it is confusing to have a file named "XXX_XXX_X"; then find its contents to be another string of merely "XXXXXXXXXXXXXXXXXXX_" characters. 2. This is because S!X is no longer using the "X_" stored in USER.DATA or "PRESETS" to actually determine which Conferences you have access to. Rather it is merely storing a <string> which corresponds to a file of ***EXACTLY THE SAME NAME*** in BBS:AreaNames/XXX_XXX_X. The ***ACTUAL ACCESSES*** are contained within the string (reading LEFT->RIGHT). This is why you DO NOT WANT to have "odd chars", "spaces", or other things except a simple "X_" pattern telling S!X which conferences to GIVE/EXCLUDE access for this user. c. I realize this may still be confusing, so let's look at the "New Name Method" of setting up your ACP.STARTUP "Presets" and BBS:AreaNames/<Names> ***AGAIN*** Refer carefully to the example in this manual in the ACP.STARTUP CHAPTER, and the example ACP.STARTUP that came with your "S!X Modular Installation Package". 1. You will see "NAMES" which correspond to the entries I have ";" DISABLED in both ACP.STARTUP. These are "Files", and each contains a <string> of characters. Let's examine the file named "COSYSOPS" which corresponds to the "XXX_XXX_X" example I used above explaining using the old stype "X_string" patterns. XXXXXXXXXXXXXXXXXXX_ This is an ASCII "string" of 20 char- aters, and tells S!X which conferences a user who's "P" field you see via ACCOUNT EDITING has access to among all **20 CONFERENCES** using the new "Extended Conferencing System". a. **NOW PLEASE NOTE** Except for the different in the <names> of "XXX_XXX_X" VS COSYSOPS that each file has ***EXACTLY THE SAME*** contents. 2. Therefore either one will describe the CONFERENCE ACCESSES I wish to give a "XXX_XXX_X" or "COSYSOPS". 3. "Recheck" BBS:Conf(s) and ACP.STARTUP to physcially insure that you have created the desired additional conferences. Using my example ACP.STARTUP, you would have to create CONF(7) AmiEMULATORS thru CONF(20) InterNET. [ED NOTE....I didn't create all 25 as ran out of ideas]. a. This means you must have physically created these DIR(s), such as BBS:InterNET BBS:Emulators. It also means that you have created the required basic SubDirs within each Conf(x), such as HOLD, UPLOAD, and LCFiles; you also will need to create key conference files such as paths and ulpaths. b. Review your "S!X Modular Installation Package"!!!! I have created (20) working conference 'skeletons' for you. You can change the names of these to your tastes as all the critical paths and ulpaths were configured to work totally within your BBS: Later you can edit these, adding additional paths, ulpaths, or other options you might wish to enhance your system. 4. "Creating New Extended Config Files" a. FIRST - look at the **SIX (6) EXAMPLES that came with your S!X Modular Installation Package. These correspond to your (6) presets used in ACP.STARTUP and ACCOUNT EDITING. They are plain ASCII files. You merely decide which conferences you wish the person to have access, and type in the corresponding "X_" pattern. ****REMEMBER TO START AT COL#1****. After you ender your string, merely hit RETURN. Then save this file. Continue creating your (6) Presets in this fashion, using the examples in your "S!X Modular Installation Package" as examples. b. SECOND PHASE - Creating "Custom Configurations" There may be cases where your (6) ACP.STARTUP or ACCOUNT EDITING presets may not be enough options when using "Extended Conf(s)." 1. Therefore we have created a way for you to create up to 256 totally different configurations, to allow you the most flexibility in granting accesses to various conferences. 2. You can create within BBS:Areanames/<file> a new file of ***ANY PATTERN*** so long as: a. It is (9) chars using only "X" and "_" b. Inside each file you edit a <string> which is correct for the accesses you wish this "X_" file to represent. 3. ***HINT*** "Advanced" DOS users will recognize this as equal to the binary 2*n type equation. Starting with a pattern of _________ and ending with XXXXXXXXX there are 256 possible combinations. =========================================================== ******NOW A WORD OF CAUTION or UNDERSTANDING....maybe just sheer confusion but I'll try to explain coherently******** 4. S!X determines "Access" level in the following priority: 1. GET USER'S "X_" PATTERN....as you log on it looks at USER.DATA and gets this (9) char "X_" pattern. 2. IF EXISTS BBS:Areanames/<user "X_" pattern.... +++++++PAY ATTENTION....WAKE UP....GET SOME COFFEE!!!++++ It doesn't matter "one-teeny-bit" what pattern from among the (256) possible you give a user ***IF*** you have a corresponding file in BBS:AreaNames/"This pattern". TRUE = The all "CONFERENCE ACCESSES" will be determined TOTALLY and COMPLETELY from whatever you have put in that particular file. FALSE = Then use the "X_" pattern in his USER.DATA to determine which areas user has access to. 3. In other words, if there IS NOT "Matching Pattern" to his USER.DATA in BBS:AreaNames/<patterns> it will use the (9) character string from USER.DATA........and you are automatically saying this user can not use any of your "Extended Conferences" 4. If there IS a "Match" between the USER.DATA and any entry in BBS:AreaNames/<patterns>.....then all the user's accesses are determined from the file in BBS:AreaNames/<user's pattern>. The (9) characters in his USER.DATA mean absolutely nothing as far as access.........it is only one of the 256 possible combinations we use. 5. ***BUT***.....Which way should I "Configure" S!X ?? Which is the best way ?? There is no "simplistic" answer. Let me say that I **PERSONALLY** favor using the old "X_" patterns (which I will explain), while others will prefer the new "Names". a. Using the old "X_" patterns will limit you to 256 MAXIMUM different configurations. ( Those knowing "Binary" or "Programming" will recognize this as a 2*n where n=9) While I can't imagine 256 different combinations (most folks do not have 256 "Active Users"), it still is a limitation. b. The old "X_" patterns are like reading Egyptina "hierogliphics" and no one could remember all the patterns!!!! NO!!! This is not some deep, dark, diabolical plan we incorporated into S!X for **SECURITY***....nor to drive you "crazy".....and certainly not to "Encrypt" your S!X as Mr. Hodge did with his USER.DATA/KEYS. YES!! It is a simple way to maintain your old "X_" patterns for the original 9 Conf(s), yet extend them to 25+ providing you make the entries correctly ***NOTE*** In the "examples" they DO NOT CORRESPOND CORRECTLY. I would have to edit them to do so. 1. EXAMPLE: IF I EDITED XXX______ and changed the string to: XXX______X_XXX_XXX_XX or something similar, then both the string in my USER.DATA and AREANAMES would in fact "Match" for the first 9 conferences. c. This is the real **ADVANTAGE** of using the old "X_" patterns. There are litterally "thousands" of "DOORS" which have been written which can be used with S!X. Many of these get their information from the X_ fields, such as many of the "Stats" type doors. They **ARE NOT** going to understand "Name" entries in your USER.DATA such as: Tom, MaPals, \/\/h0, and similar entries. ***THIS IS WHY I USE THE "old" pattern. d. The new "NAMES" patterns allows you to use the first 9 chars of a user's name, or certain "Pre-Defined Names" with almost limitless combinations. EXMAPLES: NewUsers, CoSYSOPS, MSDosUser, MACuser, InterNETS, "Tommie", "Doc", "The_Dog" 1. The ***Doc*** example. Included in your S!X Modular Install Package in the BBS:AreaNames dir is a file called "Doc". a. Open you ACCOUNT EDITOR and hit "P" on your "S!X" SLOT#1 sample SysOP account. b. Enter: "Doc " RETURN 2. Now if you do a "Local LogON" you will find you have access to all the **ODD_NUMBERED CONFERENCES**, but no access to "even-numbers". I did this just as an example to show you how it works. 3. You can even make a file <**GRINS**> called either "NONE" or "_________". If you edit this file in BBS:Areanames/<NONE|_________> to the following: XXXXXXXXXXXXXXXXXXXX a. BOY!!!! Maybe this is some diabolical scheme to confuse either YOU or potential "Hackers". It would appear the gent has absolutely NO ACCESS WHATSOEVER......when in fact he has access to "Every Darn Conference" on my BBS!! b. Ahhh.....let's not see some "goof-ball hacks" out there really try such stupidity. IF YOU DO ***I PROMISE*** WE'LL JUST CHANGE THIS AND NOT GIVE YOU SO MUCH FREEDOM!!!!! 5. I realize all this is new, and DARN CONFUSING. It took me 3-4 InterNET E-Mails to Steve and Chris to understand all the options and get just this "Rough Draft" of this section done in the manual. I can't say, "If all else fails...read the docs" (BECAUSE I'M THE "Confusion" THAT WROTE THEM). SO if you are still lost in CHAPTER 9, call any of the S!X Support Systems or "me" and we'll work it all out. 10. CHAPTER 10 - Editing Accounts with S!X ACCOUNT EDITOR ===================================================== ************************************************************* CHAPTER 10 - Editing Accounts with S!X ACCOUNT EDITOR ************************************************************* You may access the S!X ACCOUNT EDITOR from any of the following means: 1. ACP - 1> Press the Accounts button 2> Press the NODE 0 button 2. AWAITSCREEN - This is the Display Screen showing for any "active" S!X Node(x) while awaiting a caller: Press: F6 3. "ONLINE"- While actively on any S!X Node(x), you may access "Account Editor" by entering "1" at any PROMPT. No matter which way you access "S!X Account Editor", you should see the following: ------------------------------------- S>earch by name N>ew account editing Edit which account? ------------------------------------- a. Entering "S" will bring up a PROMPT asking for the "UserName". You can use (*) WILDCARDING, Do* to find Doc Sig* to find Sigma SEVEN! If more than one account is located via (*) WILDCARDING, S!X will ask if this is the correct account, or prompt you for the next account matching your WILDCARD pattern. b. Entering "N" searches for **NEW ACCOUNTS** by reading the "S" field withing the S!X Account Editor. These would be new callers you have not validated. 1. You **MUST** validate all new accounts. The "S" flag stays as =NEW= even though the caller may make several calls to your system. 2. S!X Account Editor will continue searching for NEW CALLERS until no new are found by repeating this process to validate new members. c. Entering any valid ACCOUNT NUMBER will immediately switch S!X Account Editor to this account. 1. This can sometimes be "difficult", as you will not likely remember every user's "Account Number". In learning how to use S!X Account Editor, let's enter "1" for the ==SYSOP ACCOUNT==. This account should have the name: S!X for those working with an S!X Modular Install Package. You now should see about a 19 line screen with the following information: <KORECT> S!X V0.39S-U now used the commands: >T< and >Z< for control of Relative Conference Accounting. For now see REVISION.DOC until I can update the manual. ------------------------------------------------------------------------- User Number ........: [1 ][Active] Baud Rate .............: 11264 A) Handle ..........: S!X B) Location ........: S!X Development C) Password ........: password (123456789) D) Phone Number ....: 614-855-3114 P) Conference Access ..: XXXXXXXXX E) Ratio ...........: 5 Q) Security Level .....: 255 F) Ratio Type ......: 0 <-Byte) R) Auto ReJoin ........: 1 G) Uploads .........: 0 S) New User ...........: No H) Downloads .......: 0 T) Conf Accounting.....: BBS Defaults I) Upload Bytes ....: 0 U) Total Calls ........: 1 J) Download Bytes ..: 0 V) ANSI ...............: ASK K) Byte Limit ......: 99999999 W) Time Limit (Mins) ..: 1666 L) **RESERVED**.....: 99999999 X) Time Used (Mins) ..: 0 M) Upload CPS ......: 0 Y) Computer Type ......: Amiga 2000 N) Download CPS ....: 0 Z) Conference Accounting O) Messages ........: 2 Last Called : Thu Feb 02 00:17:45 1995 !=EXIT-NOSAVE TAB=Cont ~=SAVE 1-6=Presets 9=RE-ACTIVATE DEL=DELETE Use '?' to show this Users Questionaire! [S] - Search by name, [N] - New account editing Edit which account? (Number or Option):> -------------------------------------------------------------------------- -------------------------------------------------------------------------- ****GENERAL RULES OF ACCOUNT EDITING**** S!X used what are called "Universal Keyboard Syntax Commands". Generally this means that any command I describe in one section of the manual works throughout S!X whether it is the ACCOUNT EDITOR, E-MAIL, or other areas. S!X also uses "Command Stacking", meaning it is very similar to your DOS CLI/SHELL environment where you can enter a command with many qualifiers or "flags". Just remember these (2) facts as you read throughout the manual.........it "usually works" everywhere the same to make it easy to run, call, or maintain an S!X System. EXAMPLE "KEYBOARD COMMANDS": CTRL-X=delete line DEL|BACKSPACE=delete character EXAMPLE "COMMAND STACKING" : N -10 3= NewFiles in Dir(x) last 10 days Having said the above.....let's move on into actual "Editing". --------------------------------------------------------------------------- --------------------------------------------------------------------------- "A" ACCOUNT_NAME This is the name that everyone will know that person as, the name to which E-Mail will be SENT/RECEIVED, and the name for any other "Doors" or statistics will refer. 1. It is a good practice not to let people change their name themselves. [SEE "W" Command in manual] It will cause many commands to malfuction, (i.e. "Mail"), it will cause you and other constant confusion ("who" is the person), and is a very poor general practice. 2. It is also a "Poor Practice" to have many so-called **SPECIAL CHARATERS** in a name:s \/\/ølfmæn. This makes it difficult to remember or enter the name. Some international callers may not even have the correct characters in their keymaps. 3. The PROMTP> will appear at the end of whatever string is entered. You can use either the BACKSPACE|DEL to erase a single character or CTRL-X to erase the either entry. "B" ACCOUNT_LOCATION This is the "home location" of this user. Normally it is either a City/State or City/Country; it can be the user's BBS Name for other "Guests" which are also SysOPs. This can be quite interesting information to show the variety of callers on your system, their locations from a few city blocks to "Globally". "C" ACCOUNT_PASSWORD This is sensitive ***SECURITY INFORMATION***. Anyone who has the ACCOUNT_NAME and his ACCOUNT_PASSWORD can enter the system. 1. **EXCEPTION** PHONECHECK is a "2nd password check" which S!X offers requiring the caller to know the LAST_4_DIGITS of his phone number. I strongly suggest you use this option. [SEE: PHONECHECK in S!X Manual] 2. People should be encouraged not to use "common names" and to change PASSWORDS often. This is responsible for 35%+- of illegal "hacks" to a system. "D" PHONE_NUMBER Again, you should require a "valid #" for all your users. There are both systems and users who do not want to give valid numbers; I can't suggest enough just letting them call elsewhere. Remember that USA is normally designated as 614-855-3114, whereas inter- national is +49 573 140094, being COUNTRY, CITY, INDEX. However, you may have to leave out the " " and just use +49573140094. "E" RATIO This is the RATIO which the user must maintain to DOWNLOAD; I intentionally did not include "Upload" as there is **NEVER** a restriction on how many files someone can upload except your amount of storage and the user's ACCESS_LEVEL which is explained in ACP.STARTUP, Chapter 4-5. There are (2) different ways of setting ratios with S!X: "0" - This is ***DISABLED***. Any user set to "0" can download an UNLIMITED amount of either FILES, BYTES, or FILES & BYTES limited only by his DAILY_TIME_LIMIT and DAILY_BYTE_LIMIT which you defined in ACP.STARTUP or CONFIG(x). "1-###"- This can be a ratio of either FILES, BYTES, or a combination of FILES & BYTES to those he has uploaded. It can be any value from 1 - 99999, although value beyond 20 are impractical and should probably just be a "0" for DISABLED. Your RATIO works in conjuction with RATIO TYPE (following), but is always a standard math ratio such as 1:5 or 1:3, except that both BYTES & FILES have special considerations. "F" RATIO TYPE This will define how you will measure users' uploads against their downloads. COMMON USAGE is "Bytes", but you have these choices. "0" - BYTES which will compare the actual #BYTES_UPLOADED to the #BYTES_DOWNLOADED, so a user with 1MEG uploaded and a ratio of 5:1......would be able to D/L 5MEGS. This option counts **ONLY BYTES**. He can UPLOAD 1 file of 1MEG, yet D/L 1000 files so long as the TOTAL BYTES is equal or less to 5MEGS. "1" - BYTES & FILES is the "most restrictive" way to configure S!X. This required the user to maintain the proper RATIO of "both" files and bytes. He could upload 5 files totally 1MEG, but could only D/L 25 files of 10K each. This is not "Commonly Used" as it seems to penalize folks who D/L many small UTILITIES, "Doors", MODS, PIX, and other files but may U/L many large files to your system. (We DO NOT suggest using this....) "2" - FILES is the "most generous", depending on whom you discuss the issue. Here a user could literally UPLOAD 1 file of 10bytes (his name in a text file), yet D/L 5 files of perhaps 1.4MEGS each (TOTAL 7MEGS). This was used in older BBS and some "Pay Nets", but we do not suggest it due to many possible abuses. "G" NUMBER UPLOADS This is the physical NUMBER_OF_FILES the user has uploaded to your S!X BBS. It may|maynot be used in computing the user's RATIO, but is often used by many "Doors" in displaying interesting statistics on your system's activity. The field can be edited to allow the SysOP to credit users for files which might have been "/" PRIVATE UPLOADS or even files mailed in so-called "Disk Exchanges. "H" NUMBER DOWNLOADS This is the same as "G", except it measures the physical NUMBER_OF_ FILES the user has downloaded from your system "I" UPLOADED BYTES This is probably the field you and users will monitor most often. It tells you the actual "BYTES" uploaded to your system, and it used with both RATIO and RATIO TYPE on most S!X BBS to determine how much a user can D/L from your system. It is also used in a variety of "Doors" displaying stats. 1. An "extremely active" user can literally overload the "I" field, although this is a rare situation. In case of a high RATIO and a user with say 600MEGS of upload bytes, you can exceed what is called a ULONG to programmers (about 2.2+ GigaBytes).....I mention this strictly in passing in case anyone has such a user and his account develops strange "bugs". "J" DOWNLOADED BYTES This is the NUMBER_OF_BYTES the user has D/Led from your system. It is controlled by RATIO, RATIO TYPE, and DAILY_BYTE_LIMIT. (Again there is **NEVER A LIMIT** on U/L activities). The user must maintain his DOWNLOAD BYTES within the ratio you have established, unless you use the "Files Only" method of determining RATIO on you S!X BBS. "K" DAILY_BYTE_LIMIT This command should be set with some thought. Previously it was used to limit the MAX NUMBER BYTES a user could D/L in any given "day", and was in the range of 2-5megs with older 2400 - 9600bps modems. Today with high-speed V.32 and V.34 you should use a formula which I described earlier: DAILY_TIME(secs) x MODEM'S HIGHEST SPEED (bps/sec) = DAILY_BYTE_LIMIT. In practical explanation a 14.4 can do @ 6MEGS/HR; a 28.8 can do @12-13MEGS/HR. So chose this value, and the user's DAILY_TIME_LIMIT with thought so people do not waste their time nor system resources. "L" ****RESERVED*** - for future use "M" UPLOAD CPS This is of use primarily for statistical "Doors" and also to often check against a user's *ANSWERS* to see if there is any problems in "upload/download speeds". It records the highest CPS which this user was able to achieve calling your system "N" DOWNLOAD CPS A "mirror" of UPLOAD CPS, this field records the user's fastest speed (cps) in downloading from your system. "O" MESSAGES POSTED This field is used by many SysOPS to promote more than just U/D activity on their systems. There are numerous S!X "Doors" which do statistic reports of message activity, and a few "Doors" which will not allow U/D activities unless a user maintains a certain "MESSAGE_LEVEL_ACTIVITY" on the system. 1, "Rebuilding" a MsgBASE ***SHOULD NOT*** alter this field !!! This is a historical entry for this user's account, and I've only see one S!X util which wrongly changed this entry. "P" CONFERENCE ACCESS [ READ CHAPTER 9.....thoroughly and completely!!!!! ] [ READ CHAPTER 4-5...regarding ACP.STARTUP and CONFIG(x) ] Starting with V0.39l(x) of S!X, you can now have "Extended Conferences. 1. If you have nine (9) or less conferences, you can use "P" in conjunction with the values you set in either ACP.STARTUP or CONFIG(x) to have "PRESETS" which will reflect ***ACTUAL CONF(x) ACCESS*** for the user. 2. If you use "Extended Conferences" you must be very careful in using the "P" command. You can use it to define the ***ACTUAL CONF(x) ACCESS*** or to define some "X_" file definition in BBS:AreaNames/"X_patterns" for your "Extended Conferences. 3. You can edit this manually. X=ACCESS _=ACCESS "disabled". Again I **CAUTION EVERYONE***. Read the chapters regarding ACP.STARTUP, CONFIG, and "Extended Conference" to avoid confusion, problems, and failures. "Q" SECURITY ACCESS LEVEL This is the "LEVEL" of security you assign each user. Understand that this level controls ****MANY FACTORS**** such as access to "Doors", SysOP access, and other functions. You previously defined various levels in your (6) ACP.STARTUP "Presets". <NO_DEF> "Lockout" texts....within "Q" Sorry, but I will try to write how to better use ACCESS=0-2 in a later revision. First let me explain as much of the basics....then the "Glitz!!" 1. Normally levels 10-199 are for "Normal Users", the higher numbers being either a designation or REWARD to your better users 2. LEVEL=200 - 250 Normally **SysOP FUNCTIONS** began at access LEVEL=200, such as EALL. Many "Doors" you use will come with pre-defined values in the range of 200-250 for the SysOP control values. 3. LEVEL=255 This is usually only for SLOT#1 or "You" for **SECURITY REASONS**. You may have 1-2 other EXTREMELY WELL-TRUSTED PEOPLE, or "Co-Sysops", at this level. Again I can not urge *CAUTION* enough as 65% of "breakins" are traced to "Co-SysOP" accesses. "R" AUTO-REJOIN CONFERENCE This number defines the Conf(x) the user will rejoin automatically in logging onto S!X. It is not ofter normally changed by the SysOP, but could be if he wanted you to notice a certain BULLETIN or asked that you D/L a certain file. "S" NEW USER This field tells whether the user has been "Validated" by the SysOP. 1. "New Users" will remain new until you (the "SysOP") do something with the ACCOUNT EDITOR!!! Until you "Save" their account, they maintain "new" status, if that is 5 years from now. This was added to allow you a chance to read the user's application and see how he acts on your system, or you may chose to wait until he uploads a few files or posts some messages. 2. "Auto-Validation" Many S!X SysOPS will chose to "auto-validate" users. This means setting your PRESETS so the user has access to your basic conferences and commands, i.e. LEVEL 10-40. In this way he does not have to make several calls to actually use your system, and you get a chance to "Wait-n-See" before finally deciding whether he should have a permanent account on your system. <KORECT> Now used for RELATIVE CONF.....see REVISION DOC "T" CONFERENCE ACCOUNTING This is an "OverRide Function" for INDIVIDUAL USERS. Generally whether you use RELATIVE CONFERENCE ACCOUNTING is determined in your ACP.STARTUP, but sometimes you may want individual users which are good supporters not being forced into having to maintain ratios in EACH Conf(). Hitting "T" will bring forth (3) options: Choose one of the following Options: 0. Default to BBS Configured Conference Accounting 1. Override Conference Accounting to YES / ON 2. Override Conference Accounting to NO / OFF "U" TOTAL TIMES CALLED This shows the total number of times this user has logged onto your S!X BBS. As long as you maintain the integrity of your BBS:USER.DATA and BBS:USER.KEY files, you can safely upgrade from V2.0 - V4.9 of /X or any S!X without losing any information. [Ed Note: Maybe I should repead that elsewhere, but for now let me reiterate that any "revision" of /X or S!X to a new S!X will not destroy or alter ****ANY***** of the fields in your USER.DATA or USER.KEY files !!!! ] "V" DO YOU WANT TO USE ANSI Here you have (3) choices 1. NO - This will convert S!X to a "Black-n-White" 1-BITPLANE mode. In this mode S!X automatically filters all ANSI sequences (i.e. ESC[44;31m"Hi S!X") showing only plain text. This mode is used by folks having terms not supporting COLOR or a few claiming that 1-BITPLANE mode improves file transfer performance. 2. ASK- Upon "Logon" the user has the option of chosing either YES or NO, meaning to use or not use ANSI. 3. YES- Using ANSI mode displays all normal ANSI sequences for Amiga. You should be able to see "8-color-mode" with "bold/underline/italic", and ANSI sequences which seem to "draw" text written graphics on your screen. Personally, I always use ANSI. In calling a S!X BBS part of the excitment is seeing the highly colored texts, bulls, dirs, and screens SysOPS take many hours to create. Calling a dull "Plain Janer" is borish!! "W" DAILY TIME LIMIT This displays how long a user may be on your S!X daily, and computes from 12:00AM (Midnight) until 11:59PM of the same day. The display is in "MINUTES", meaning that a limit of '120' equals 2 HOURS 0 MIN. 1. You should give users "realistic values" considering the following factors from the experiences of many SysOPS: a. Number of Nodes - obvious if you are "multi-noded" you can have more users that a 1-modem BBS. b. Number of Users - can everyone call you without having to "wardial" for hours c. RATIOS/ACTIVITY - compared to other users, how much of your system's daily time should this one person enjoy. There are obviously other factors, but I wanted to make you think of your S!X BBS as a "resource". Just like your wallet it is normally "finite"; you should allocate your resources as will best serve your basic ideas and the most possible people effectively. "X" DAILY TIME USED If the user has not logged on today, this value should be "0". If he has called your system, it will display the TOTAL NUMBER MINUTES he has used during "today". 1. Occasionally, SysOP's will clear this field to "0" for a user who is doing "heavy work" which is valuable to the SysOP or because a user needs extra time to make unusually large D/Ls. A few "Doors" exist which allow users to put extra time in a **BANK** from which they can withdrawl and use extra time on days when they need more than normal. (e.g. Tarheel's Timebank). "Y" COMPUTER TYPE This command works with your BBS:BBstexts/ComputerList file. It was answered by the user when he first applied, or in using the "W" command to update this information. However a SysOP can edit this field to help a new user or change faulty information, or when he has "edited" the BBS:BBStexts/ComputerList file to list new entries or deletions. <KORECT> Now used with the RELATIVE CONF SYSTEM....See REVISION DOC "Z" An EARLY implementation of Conference_Accounting_Editing now exists. Simply hit the "Z" and you get the internal editor. How it basically works: 1. Select the Conf() you wish to edit such as: 0 Ami 1 PC 2 MAC 2. The enter the "field" you wish to edit as shown: 1) Files Uploaded...: 11 2) Files D`loaded...: 0 3) Bytes Downloaded.: 0 4) Bytes Uploaded...: 58493945 0) QUIT (with SAVE) 9) QUIT (without SAVE) 3. Then enter the NEW VALUE for that "Field" 4. When finished editing, select either "0" (SAVE) or "9" (NO SAVE) to return to the main ACCOUNT EDITOR. ========================================================================= ========================================================================= We now have finished covering the basic information you can change regarding any user's account. Once you are finished editing the account, you obviously want to either SAVE, NOT SAVE, DELETE USER, or do something with the information you edited. You will see the following OPTIONS: !=EXIT-NOSAVE TAB=Cont ~=SAVE 1-6=Presets 9=RE-ACTIVATE DEL=DELETE Use '?' to show this Users Questionaire! "!" This is "SHIFT-1" on a USA keyboard or the "!" EXCLAMATION KEY. You will exit from the user's account and no changes will be saved. It is used primary as a "look-up" of an account for information without actually wanting to edit the account. "TAB" This is your "TAB" key. It takes you back to the prompt asking for either an ACCOUNT # or hitting "S" to search for a user's name by <string> method. "~" This is "SHIFT-`" or TILDE or sometimes called "wave" key. It causes all "editing" into the user's account to be saved. 1. EXCEPTION: A "Co-SysOP" nor even the "SysOP" can edit his own account from activating the ACCOUNT EDITOR using the "1" command SLOT#1 "You" can not edit your account EXCEPT and ONLY from the "F6" key directly from your keyboard....it ***CAN NOT*** be done while "Online" S!X These exceptions are for obvious ***SECURITY REASONS*** so no one having SysOP access could delete the SLOT#1 or change his access, give a "Co-SysOP" better access, or other changes which violate the basic concepts of good system security. Obviously LEVEL=255 can edit LEVEL=250; LEVEL=200 in turn can edit LEVEL=40 accounts. But you can't have a "Co-SysOP" LEVEL=200 going and "Deleting" a LEVEL=255 account. "1-6" These will use the "PRESETS" defined you your ACP.STARTUPS to preset many of the fields of a user's account such as DAILY TIME, ACCESS LEVEL, RATIO, and other fields. [SEE CHAPTERS ON ACP.START and CONFIG(x)]. 1. "Extended Conferences" if you operate (9) or less Conf(x), you can use the PRESETS to define CONF ACCESSES "P" in your ACCOUNT EDITOR. 2. If you plan on using **MORE THAN 9 CONFERENCES**, please re-read the special cautions and descriptions given in CHAPTER 9 - EXTENDED CONFERENCES. "9" RE-ACTIVATE "Inactive" ACCOUNT is a command that we hope you do not need to use often. It is used primarily for security reasons. 1. You may save a user's USER.DATA but "Inactivate" an account should the user be away for an extended period such as vacations, college, or other reasons using the DEL key. Then you can "RE-ACTIVATE" the account using this key. 2. Sadly, some members might abuse your system, forcing you to take "enforcement actions". The "Re-Activate" feature is to let someone back into your system following such an incident. "DEL" The "DELETE" key is the one your users will probably dread, especially if you are forced to take "enforcement actions". 1. "DEL" ***DOES NOT*** destroy the user's USER.DATA or USER.KEY information. Rather it "inactivates" his account <saving the information> so that he can not log onto the S!X BBS. 2. "Deleted Users" must log back onto S!X BBS as "New Users". They will have to fill out your application, (if used), and must know any "NEW_USER_PASSWORD" or "SYSTEM_PASSWORD" just like any other new user. This is a pretty drastic step, but one which is sadly forced upon many SysOPs often. You have saved his old USER.DATA/KEYS so that "if he follows the rules", you can chose to restore his old stats or make him start all over again with a new account. 3. ****CAVEAT**** Several S!X "Door" and CLI/SHELL routines will erase USER.DATA/KEY files on users which are "Deleted". A good example is Ron Shaw's, aka "Spazm's" UDCRUNCH. **SPECIAL UNSHOWN KEYS** KEYPAD "Keypad" keys should work for all "keymaps" for RETURN, 0-9, +, - keys. This is a 'shortcut' many of us use, but is not shown in display to save screen lines. "+" PLUS_KEY "+" will automatically take you *FORWARD* one user in your ACCOUNT EDITOR. If you have "edited" the user's data, it will automatically be SAVED. This is another of the "power-user shortcuts" not shown. "-" MINUS KEY "-" is the opposite of PLUS. It takes you back one user, (i.e. SLOT# less 1) and also will SAVE any fields which you might have "edited". "RET" RETURN is used as a sort of "CD", taking you up one higher level in the ACCOUNT EDITING menu and logic. Hitting RET twice will usually return to either "Awaiting A Caller" if started with F6 or return you to a main PROMPT> if started via "1" while ONLINE. 11. CHAPTER 11 S!X Program Logic -OR - How it all Works!! ========================================================== ************************************************************* CHAPTER 11 S!X "Program Logic" -OR - How it all Works!! ************************************************************* I will now attempt a explanation of S!X, based upon the original AmiExpress logic; first as developed by Mike Thomas V0.9b-V1.1u and later by Joe Hodge V1.1w-2.34. <ERRATA> ***PLEASE NOTE*** This does not, at present, cover all the changes in logic which occured since the development of S!X by Stephan Schiemann. I am first trying to write a complete, coherent manual of the basics of /X and S!X historically............then I will go thru the entire REVISION.DOC and S!X SOURCE CODING trying to document all the new features in either Steve's Revision notes or things which exist but were sadly never documented from the actual source codes. <NO_DEF> Sorry, I'm dead tired and will have written more by the next "S!X Modular Install" RELEASE!!! Once all of the NODES are started the following actions take place for each node: At this point the bbs will load up the computer types from a file called: BBS:NODE(x)/COMPUTERLIST (x) indicates 1 of 9 nodes EXAMPLE: -----------(cut here)------------ 5 <- This entry describes how many computer types follow Amiga 500 <- 1st entry Amiga 1000 <- 2nd entry Amiga 2000 <- 3rd entry Amiga 3000 <- 4th entry Other <- 5th entry -----------(cut here)------------ ^ |_ | NOTE: The bbs and ACP require this file to exist in order to operate Ami-Express then checks if the node is already running as another task, and if it is, then the program halts and exits with an error message. Ami-Express will run thru it's initialisation process where it will take the modem off-hook, and configure it for BBS operation. This is done so that an incoming call does not alter the configuration process. While BBS Node(x) is in "standby mode, the following options are available via your BBS:BBSTexts/awaitscreen.txt F1 - Sysop Login F2 - Local Login (uses same logic as a "caller") F3 - Give Carrier F4 - Reserve for a User. This reserves this Node(x) for a specific user. F5 - Local SHELL F6 - Account Editor F7 - "Toggle Chat ON/OFF F8 - Reset MODEM. Better stated as "re-initialize" modem. F9 - EXIT BBS Shutdown this Node() and return the Serial() to the system F10 - EXIT BBS "OffHook" This takes Node() and that phoneline to an offhook, i.e. "BUSY" status. HELP KEY- Performs a "Screen-To-Background" command While someone is online you have the following function keys available to you: F1 - Chat in/out F2 - Increase Online time limit +10 mins SHIFT+F3 - (Version 0.39z1) This pops an ASL Requester asking for a filename to download. It replaces the SYSOP DOWNLOAD FUNCTION. Remember to change your AwaitScreen.txt. F3 - Decrease Online time limit -10 mins F4 - Asks for a path/filename for a capture file (only on the sysops side) or if one is already open then it closes the capture and lets you know it did so. when you press F4 again the capture will be stopped. SHIFT+F4 - Asks for a path/filename to ASCII send a file (only on the sysops side) SHIFT+F5 - This will "Toggle" RELATIVE CONF() ACCOUNTING function ON/OFF while User is online. This was for testing originally, but can be used to give users a "Temporary Break". F5 - Local Shell F6 - Account Editing SHIFT+F6 - This will let you change the Account of a User only for that call he is online. When he locks off the BBS will reset his Account to the old one. Press Shift+F6 a second time and the changes will be reseted to the old ones. F7 - Chat Flag toggle (whether you are to be paged or not) F8 - Serial in on/off (User can`t write until you press F8 again) F9 - Serial out on/off (User can`t see what you are typing) F10 - Keyboard out on/off (Disconnect OnLine User *KICK*) Now follows the normal reactions of AmiExpress when something happens if the bbs is in the standby mode and the nodes are standing at "Awaiting Connect". (1). The bbs checks for F key input from the local keyboard. (2). Or data coming in the serial port. (3). Or data coming in the internal commnunication AmiExpress_Node(x) msgport for commands either suspend, resume, or shutdown. (4). Or data coming in from the AmiExpress window itself (Gadgets etc..) (5). Or data coming in from AmiExpress Control.(ACP) Once the modem picks up a RING DETECT, the bbs sends an Answer string specified in the config file to the modem, and waits for a response from the remote modem. If the resultant string is a valid connect string, the bbs continues with normal operations, if not, it resets the modem and the ACP screen will return to "Awaiting Connect" state. If the connect string was a valid one, AmiExpress firstly checks a couple of things before performing the login routine: (1). System checks for a file called: BBS:NODE{x}/NOCALLERSAT{BAUD} where x is node number and BAUD is the baud rate that is unaccepted. If this file exists, and the current baud rate matches the BAUD, then the BBS displays the file and disconnects. (2). Displays the connect string received from the modem. (3). Now, the BBS displays the standard welcome message, and starts to perform the actual login procedure. (4). Check to see if you have a door called FRONTEND , if so it executes it. see section regarding doors for more info. Explanation: To Install the frontend door you have to add the following Line to the 'BBS:COMMANDS/SYS.CMD' File: -------Cut here---------- FRONTEND XM005DOORS:FRONTEND/DOORBEFORELOGON <<< That`s the Door !! -------Cut here---------- Where DOORBEFORELOGON is the door that will be executed right after the welcome message. This is a very flexible option in that it can be used with a door that checks who is online on the other nodes and their activities, and dumps this to one of the first BUllBatch bulls files that are displayed upon login. This is just an example, but it`s there to be explored. For more information on doors, please refer to the docs on advanced Door-Protocols and Implementation. (5). BBS checks if there is a door called "ANSI" in the SYS.CMD, if so it will start the door you insert and will skip the selecting of ANSI or ASCII Colors. Look at Point (4) above for more infos about installing these doors. If the BBS can`t find such a door it will asks if the user wants ANSI graphics or not. If a 'Q' is specified at the end of the line like: "YES Q" or "Y Q" etc. Then the BBS checks if the Option SUPPRESS_QLOGON is on or not if the option is on the BBS will display the Logon.txt because you want to have the users seen it. If the Option is off and the user answers "Y Q" or "YES Q" the BBS will not display the logon or logoff screens. (6). Then if the sysop has specified a SYSTEM PASSWORD it displays a file called: BBS:NODEx/PRIVATE.txt(.gr) then asks for the SYSTEM PASSWORD. The system gives the user three tries and if by then he hasn't gotten it the bbs hangs up, and displays in the callerslog that someone attempted to get the SYSTEM PASSWORD. (7). The bbs displays the file: BBS:NODE{x}/BBSTITLE.txt(.gr) (8). It now asks for the user to enter his FULL NAME, again wildcards are usable and will expand and ask if correct. A user gets five tries at his user name, then the bbs hangs up. (9). Now the BBS checks for a File called BBS:NODE{x}/NOTTHISNODE.TXT and if the BBS finds such a file it will look in it and if there is the name of the User who is online, the BBS will display the Textfile BBS:NODE{x}/NOTTHISNODE.MSG and logs the user off... (10). If the bbs can't find the name supplied it will tell the user and ask him if he would like to 'C'ontinue to join or 'R'etry entering his name again. [C]ontinue as a New User Selected: ---------------------------------- (1). If the bbs has been reserved it will notify the user that the bbs has been reserved for a specific member and will then hangup. (2). If the bbs hasn't been reserved then the bbs checks to see if the user's baud rate is allowed during the time he has called. If so, then the bbs allows the user to continue, otherwise it displays the file: BBS:NODE{x}/NOTTIME{BAUD}.txt(.gr) {x} = Node number, {BAUD} = Current Baud rate. (3). If the sysop has specified a new user password in the config file then the bbs displays the file: BBS:NODE{x}/NEWUSERPW.txt(.gr) Then it asks for the new user password and if the user gets the password wrong it goes back and asks for his FULL NAME again, after 5 tries the bbs hangs up. (4). If the System-Operator wishes to have no more NEW users the bbs would look for the file BBS:NODE{x}/NONEWUSERS then displays it and disconnect the User. And if you wishes to have no more NEW users at a SPECIFIC BAUD RATES, the BBS would look for a file called BBS:NODE{x}/NONEWAT{BAUD}, displays it and then disconnecting the User. {x} = Node number, {BAUD} = Current Baud rate. (5). Now it enters the New Account routines. 1. Search displays BBS:NODE{x}/JOIN.txt(.gr) 2. Asks for full name. At this point wildcards are NOT ALLOWED. The user only has 5 chances to enter it then the bbs says "Too Many Errors, Goodbye!" 3. The bbs checks for use of a name that already exists. If the name already exists it asks again. 4. The bbs checks the name given to see if not in the list of names supplied in the file BBS:NODE{x}/NAMESNOTALLOWED This is a file that contains names that the sysop does not want to allow on the bbs. If the file does not exists the bbs will not allow any new users to log on util the file has been added. This is to prevent someone getting on as ALL or EALL etc. A notice will be placed at the end of the BBS:NODE{x}/CALLERSLOG file. WARNING: You should specify in that list SYSOP, ALL, and EALL 5. Next it asks for the City, State. 6. The it asks for Phone Number (xxx-xxx-xxxx) 7. Next, it asks for the Users personal Password 8. Number of lines on screen (1-255) 9. Clear Screen between Messages ? 10. Display back all info and asks if it is correct if the user needs to change something he just says no its not correct and the process starts again at 2.. 11. At this point the bbs checks to see if there is a script questionaire to ask the user to fill out, it checks for BBS:NODE{x}/SCRIPT{BAUD} {x} = Node number, {BAUD} = Current Baud rate. NOTE: The {BAUD} should be specified as 1200,2400,4800, 9600, 12000, 14400 and 16800 to allow for proper connect handling by USR HST modems. 1. V0.35+ you **DO NOT** need the {baud}. It will default to "script", but you can specify "Script{baud} if you want to answer different questions based on their connect speeds Now the user is asked to fill out the script if existent. A sample script may look like: -------------Cut Here-------------------- What is your Real Name: ~ What is your Real # : ~ What is your Sex,Age : ~ -------------Cut here-------------------- Here, the ~ character is used when a prompt for input by the user is expected. The answers are saved to BBS:ANSWERS before being validated by the sysop. <ERRATA> ***NOTE* As of V0.39h you must create a directory called BBS:Answers in which all your new user questionaires will be placed. Hitting the "?" from your ACCOUNT EDITOR will then display that user's answers to you automatically.....[end this ERRATA]. 12. The bbs then displays the file BBS:NODE{x}/JOINED.txt(.gr) (10). Once the system has loaded the users account, it checks to see if the system has been reserved, if so and the user who just logged in is not the reserved user the bbs displays that the system has been reserved for that specific user, and then hangs up. (11). Then the BBS will display the BBS:NODE{x}/LOGON{y}.txt(.gr) texts where x stands for the Node and y for the number of the Logon texts. if there are random Logontexts installed in the BBS:SCREENS Directory this one will be displayed. (12). If the bbs hasn't been reserved then the bbs checks to see if the user's baud rate is allowed during the time he has called. If so, then the bbs allows the user to continue, otherwise it displays the file: BBS:NODE{x}/NOTTIME{BAUD}.txt(.gr) (13). If the users Security level is 0 then the bbs displays the file: BBS:NODE{x}/LOCKOUT-0.txt(.gr) and then hangs up. (14). If the users Security level is 1 then the bbs displays the file: BBS:NODE{x}/LOCKOUT-1.txt(.gr) and then hangs up. NOTE: These two files allow a sysop to be either polite about not allowing a user on the system, or if the user is an abuser, the sysop can have a full blown rude as hell Lockout text for those types of users. (15). At this point the system adds to the end of BBS:NODE{x}/CALLERSLOG that a user just logged in. (16). Now the bbs asks the user for his password, every time the user gets the password wrong the bbs adds what he tried to the end of BBS:NODE{x}/CALLERSLOG. After 3 tries the bbs hangs up and adds this to the Callerslog. (17). The bbs checks to see if the beginning of the username starts with "UUCP." if it does and the user has access to do UUCP, it drops to UUCICO on the serial port. For more information on how to implement UUCP for the Amiga, and with AmiExpress, refer to the section on NETMAIL with Express. (18). Then the standard logon sequence takes place and puts the user at the main command prompt LOGON SEQUENCE FOR A PREVIOUS USER: ----------------------------------- When a user with an existing account logs into the BBS, the login procedure is a lot more simplified. The standard login procedure is listed below: (1). The bbs checks to see if the user has any time for the day if not it displays BBS:NODE{x}/LOGON24HRS.txt(.gr) file to the user and hangs up. (2). If no BULLBATCH files are specified, the BBS looks dor any Bulletin files in BBS:NODE{x}/BULL{SEC}.txt(.gr) where {x} = NODE NUMBER and {SEC} = USERS CURRENT SECURITY LEVEL. If a file is found that matches the user`s security level, it is displayed. For example, a last callers bulletin for standard user security of 20 would be saved in the BBS:NODE{x} directory as follows: BBS:NODE{x}/BULL20.TXT and BBS:NODE{x}/BULL20.TXT.GR. This routine has also been simplified from the sysop's end so that the appropriate bulletins are searched for in a rounded off method. ie: If a user level with security level of 20 has logged in, and the bbs can NOT find an entry for BBS:NODE{x}/BULL20.TXT but finds a file called BBS:NODE{x}/BULL15.TXT, then this file will be displayed. If there is also a file called BBS:NODE{x}/BULL30.TXT, this file will be displayed to users with security level of at least 30 or more. Once the BBS finds the nearest file, it displays that file only. NOTE: Routines have been added to AmiExpress to make sysop setup a little easier and less annoying to the user. The bbs will scan for a peticular file in this method: Say a user with access level 30 just logged in, with ansi color, now the BBS will check first if there is a BULL30.txt and if not the bbs will go on with searching for bulls lower than 30. Look here: BBS:NODE{x}/BULL30.txt.gr BBS:NODE{x}/BULL30.txt BBS:NODE{x}/BULL25.txt.gr BBS:NODE{x}/BULL25.txt BBS:NODE{x}/BULL20.txt.gr BBS:NODE{x}/BULL20.txt BBS:NODE{x}/BULL15.txt.gr BBS:NODE{x}/BULL15.txt BBS:NODE{x}/BULL10.txt.gr BBS:NODE{x}/BULL10.txt BBS:NODE{x}/BULL5.txt.gr BBS:NODE{x}/BULL5.txt BBS:NODE{x}/BULL.txt.gr BBS:NODE{x}/BULL.txt NOTE: because of this method of searching, all files to be searched for must end in either 0 or 5 (as above), the user access level will be rounded down to the nearest multiple of 5 and the search will start there. Thats an example of a search for a file to be displayed, once a file is found that exists it displays ONLY that file. This method is used on the following: BBS:NODE{x}/BULL BBS:NODE{x}/JOINCONF BBS:CONF/MENU BBS:CONF/BULL In some cases it works a little different, in this case the user security is not used, like: BBS:CONF/Bulletins/BULLHELP.txt.gr BBS:CONF/Bulletins/BULLHELP.TXT Thats how that one works and the following are like that: BBS:NODE{x}/JOINED BBS:NODE{x}/LOGON24HRS BBS:NODE{x}/GUESTLOGON BBS:NODE{x}/LOGON BBS:NODE{x}/LOGOFF BBS:NODE{x}/JOIN BBS:NODE{x}/NOTTIMEbaud BBS:NODE{x}/PRIVATE BBS:CONF/FILEHELP NOTE: For multiple bulletins upon login, a BULLBATCH script is used to display the necessary bulletins in the correct order. For more information on this, please refer to the section under BULLBATCH implementation. (3). Initial User specific checks are made: a> The bbs now scans thru all the conferences that the user has access privilege to for any waiting mail. If mail is found, it informs the user about it and asks the user if they want to view it. b> The bbs checks to see if there are any unfinished uploads. If someone looses carrier uploading a file and calls back he will be allowed to resume his/her upload. (4). Then the bbs rejoins the conference the user was in the last time he called. (5). It then checks the file BBS:CONF/NDIRS to see how many, if any, directories of files that specific conference has. This file would look something like this: ---------------CUT HERE------------ 2 ---------------CUT HERE------------ This would specify that there are two file directories where files are kept. A carriage return is necessary after the number. If this file is unavailable, the conference will have NO files available in it, meaning no uploads or downloads will be possible from it. (6). If the number of directories is greater than zero, the bbs looks to see if a file exists called BBS:CONF/FREEDOWNLOADS, if so then all files in this peticular conference are free to download. (7). Now, the BBS scans for any BBS:CONF/BULL{SEC}.TXT(.GR) files in the same method as described earlier on. NOTE: This works exactly like the BBS:NODEx/BULL files. (8). After displaying the available bulletins, if the user is not in EXPERT mode, the bbs displays the available BBS:CONF/MENU{SEC}.TXT(.GR) and reaches the MAIN MENU PROMPT. a> Any command entered at the MAIN MENU PROMPT will be looked up in a BBS:Commands/BBS.CMD file. If the command is found as a module name in that list then the module will be executed. If the command cannot be found, then the command will be compared to BBS:Commands/CONF{x}.CMD and like wise be executed if found. otherwise the command will be considered an internal command and maybe any of the commands listed below. NOTE: Customcommands are totally optional, If you do not have them then don't worry. 12. CHAPTER 12 S!X User Menu Commands Users Can Use ================================================= ************************************************************** CHAPTER 12 S!X "User Menu Commands" Users Can Use ************************************************************** This is a list of the "General" User Commands commonly available on all S!X BBSs. I say that with ***CAUTION***, noting that S!X has extensive abilities to use several different types of "Doors". In adding either S!X Development Utilities or those by others, you can totally redifine your Menus, add extensive additional features, or prohibit the used of commands. ALL THIS IS SYSOP CONFIGURABLE. ***REMINDER*** S!X uses what can be called either DOS arguments or "Command Stacking". While commands are usually defined as a single character, number, or "word".........these can be entered into <args> such as: F 1 N S U etc. <ERRATA> 02-21-96 Again these are from the original /X V2.34 Documents. I have much work to update this to S!X V039u3 or later. Merely I'm trying to make the manual finally a coherent copy logically without a bunch of random pages for you to scroll. SYSOP ONLY COMMANDS: ~~~~~~~~~~~~~~~~~~~ These commands are NORMALLY commands that are called up by single digit number codes. They are available only to users with SYSOP SECURITY LEVELS as defined in the config file by AmiConfig under ACCOUNT EDITING. [ 1 ] - Account Editing: ~~~~~~~~~~~~~~~ This is used to either review existing accounts and modify them, or scan for any new user logins that wish to be validated. The account editing module is very easy to use in that it is basically menu driven. You can also get into the BBSInfo Conf. from here. <ERRATA> Not functioning in V039.z6 [ 2 ] - View CallersLog: ~~~~~~~~~~~~~~~ This lets the sysop view the BBS:NODE{x}/CALLERSLOG file backwards. The last line written to the callerslog will be displayed first and the first line of the callerslog will be displayed last. On system running more than one node, this command will ask which NODE's CALLERSLOG to view. <ERRATA> Not functioning in V039z6 [ 3 ] - Edit File Directories (EDITOR/EMACS): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you started this Command, the bbs will check if the one who started the command is a remote or a local one. If the one who started it is a local one it will search for a Door called "EDITOR" in the SYS.CMD and if it exists it will be executed and the normal starting of the EMACS will be skipped. If the one who started the command is in REMOTE_LOGON then the command will be executed as follows: This command uses the command line version of MicroEmacs for on-line directory editing. For more information on how to use Emacs, you should refer to the section on COMMON EMACS COMMANDS. This command asks the user which directory to edit before it opens up the appropriate AUX: or CNN: channel and executing EMACS. NOTE: AUX{x}: is used only on remote connections and if active a watchdog task that checks for carrier loss is also invoked. If carrier is lost while editing directories, the computer will be reset withing two seconds. A special note to MULTI NODE systems: The watchdog resets the computer if a carrier is lost regardless of what the other nodes are doing. If users are logged in on other nodes, they will be disconnected when the computer resets. A later version of AmiExpress will send a notification to the other nodes and a time-out requestor locally will inform the sysop and users that express wants to reset the computer and that everyone should finish up what they're doing. Exiting from EMACS with CTRL-X CTRL-C key combination will return the user to the MAIN MENU PROMPT. While a user is in EMACS, the BBS will notify the sysop by placing a line like: User in Emacs........ WARNING! for those of you using the A2232 multi serial card you may run into problems using the editor. We are currently working on a fullscreen editor to take it's place. [ 4 ] - Edit any Text File on System (EDITOR/EMACS): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This command is basically the same as the previous with the option to specify full path and file name to edit. This commands prompts the user for the necessary information. [ 5 ] - List System Directories: ~~~~~~~~~~~~~~~~~~~~~~~ This command works just like the AMIGADOS List command and displays the directory and sub-directories available for the specified path. The command can also display any comments (FILENOTES), attached to the files themselves. When selected, AmiExpress will ask for the full path name and whether to include comments or not. [ 0 ] - Remote Shell: ~~~~~~~~~~~~ This Command has been removed currently in this version of express. There are some great door with the same capabilities soon to replace this command. if you choose one of the great doors who are out. Personallity I recommend the version of MALTESE FALCON. then install it as a normal door in your "BBS.CMD" commands and choose the 0 button for that. This sums up the SYSOP ONLY FUNCTIONS of AmiExpress. The Next section deals with the standard commands available to all users. Of course, certain command options can be disabled for specific security levels from the AmiConfig for the config file. REGULAR USER COMMANDS: ~~~~~~~~~~~~~~~~~~~~~ The following are the regular user commands. These commands are explained in detail, and any neccesary pre-requisite for the particular command to work is also outlined. All the commands here can be choosen in the ACP.STARTUP or the normal Config{x}. [ $ ] - ReScan MsgBases for Mail This command allows you to ReScan all Conf() MsgBases for new mail to you from other users of the BBS. Handy if you said "No" to NewMailScan or used the "(T)ouch" option to initially read your mail. [ A ] - Alter File Flags: ~~~~~~~~~~~~~~~~ This command allows the user to change the flagged file list without having to do a file listings and get a PAUSE...MORE prompt to change the flags. Chaining data is allowed, or the routine will prompt the user for the information. First it will show the current list of flags. No file flags Filename(s) to flag: (C)lear, (Enter)=none? At this prompt the user can: 1. Enter new files to add to the flag list 2. Enter 'C' to goto the clear flag prompt Filename(s) to Clear: (*)All, (Enter)=none? At this prompt the user can: 1. Enter filenames to remove from the flag list, wildcards are valid, however they will only remove the first entry. 2. Use '*' to remove all entries in the list. 3. Hit Return to exit. Once a user exits the Clear prompt, it will once again show the list of flagged files and drop back to the MAIN MENU PROMPT. [ B ] - Bulletins: ~~~~~~~~~ This command allows the user to view bulletins that the sysop has made available. - Firstly, the BBS checks to see if the file BBS:CONFNAME/BULLETINS/BULLHELP.TXT is available; if not, it tells the user that no bulletins are available in that conference. - If the BBS:CONFNAME/BULLETINS/BULLHELP.TXT is found, it is displayed and the user is prompted to enter the bulletin # to view or '?' to redisplay the BULLHELP.TXT which is the bulletins menu. - If a user selects a valid bulletin #, it is displayed and the bbs returns back to the bulletin prompt. - If a user selects an invalid bulletin #, the bbs informs the user that there is no bulletin #{x} where {x} = the specified bulletin. [ C ] - Comment to Sysop: ~~~~~~~~~~~~~~~~ This command is exactly the same as the regular ENTER MESSAGE command except that the message is addressed privately to the System-Operator. The TO: field is automatically filled with the User name on SLOT 1, which is the Sysop. If the BBS located a file called BBS:ForwardSysopMail then this file will be readed and the first line will be the name of the user the comment will be forwarded. for example: ----- cut here for BBS:ForwardSysopMail ----- CoSysOp --------------------------------------------- Now the bbs will forward the mail also to that user you typed in there. This is very usefull if you go to holiday and want your cosys to read the messages to yeah without typing "R" for read messages. [ D ] - Download File(s): ~~~~~~~~~~~~~~~~ This command accesses the file transfer procedure for sending files from the system to the remote user. The flow-chart for this command is quite complex and is outlined below: 1. If the BBS:CONFNAME/NDIRS is unavailable, or it contains zero, the bbs informs the user that there are no files to download from that conference. 2. The bbs displays the File DOWNLOADMSG.TXT from either BBSTEXTS or CONF() Dir 3. The bbs displays the users Download/Upload stats. 4. The bbs calculates the ratio limits the user has before uploading files to the system. 5. Next, it displays the transfer protocol to use. AmiZmodem is the only available transfer protocol at the moment. Cotile is working on implementing XPR transfer protocols so, a later revision will have full XPR support. 6. Now the bbs displays the TOP CPS Downloader in your System 7. If the user had specified 'DS' instead of just 'D' the download is considered a sysop download and if the user's security level is over 200, the download can be made from any valid AmigaDos path on the system. If this is the case, the BBS asks for the full path and filename. NO WILDCARDS ARE ALLOWED with a Sysop Download. 8. The BBS asks the user to enter the filename(s). 9. Checks for special characters in the filename like ":/" etc. If found, tells the users that special symbols may not be included when downloading. 10. Full Wildcards are allowed when doing a regular download, but just the * wildcard character alone is not allowed. ****NOTE*** You must have a file called BBS:AMI_DRIVES. If you do not create this file showing all available drives, it will default ( Version 0.39y9 ) to assuming all files are on the drive where BBS resides. 11. Now, the bbs scans the specified paths from BBS:CONFNAME/PATHS and when it finds the file that the user requested, it displays the file length in Kbytes, time required to download it at current baud rate, and checks if the user has enough credits to download the file. If so, AmiExpress checks the filename against what is in existing File Flag list and if it isn't already there, it adds it. So, if the download sequence is aborted for any reason, just hitting "D" again will download the flagged file. To remove from flaglist, the user would use the 'A' command. 12. Now the BBS checks if there is an Comment at the File like "RESTRICTED" or "FREE DOWNLOAD" ... if there is a Comment like this then the BBS will display some messages when the File has a comment like "RESTRICTED" it is not not allowed to download this file and the bbs will write a comment into the BBS:NODE{x}/CALLERSLOG that a user tried to download this File... and with this comment you can`t download this file with a level of 255 and sysop download too.. so the file is 100% save for downloading... if there is the comment "FREE DOWNLOAD" the bbs will make this file free download and it will costs no crediz to download it... 13. After hitting return alone on a filespec prompt, the bbs re-checks the totals to see if the batch is within the user's limits. 14. If so, AmiExpress asks either to start, abort, or automatically logoff at the end of the transfer. The 'G'oodbye after transfer gives the user 10 seconds to change his mind after the transfer before performing an automatic disconnect sequence. 15. At this point the download sequence is about to begin and so the necessary information is written to the BBS:NODE{x}/UDLOG. 16. At the end of the download, if the users' security level is below 255, then the user's number of downloads and number of bytes downloaded get updated with the new download stats. Look at the ACP.STARTUP Command "KEEP_UPLOAD_CREDIT" too. 17. Now the bbs checks if the DownloadCps was higher than the last record. if the CPS is higher than the record it will display a little text that the user is now the fastest Downloader. 18. At this point, the download sequence is completed, and the bbs tells the user his new stats before returning back to the MAIN MENU PROMPT. [ E ] - Enter a Message: ~~~~~~~~~~~~~~~ This command allows the user to leave private or public mail to other users on the system. There are several options with this command and they are outlined below. 1. Asks for who to send it to. If a wildcard is used the search will find the first user that fits the wildcard and will display it and then ask if its correct, if the user says no then it will search forward. If it doesn't find the user it will exit back to the mainmenu prompt. 2. If the user just hits return on the TO: prompt it will send the message to ALL. 3. A feature added in is to be able to leave a message to "EALL" this means to EMAIL ALL people, this is only usable by users with an access level that you specified in the ACP.STARTUP "EALL_LEVEL". What this does is to leave ONE message to ALL USERS , when a person calls the system it searchs for mail in that conference to that user it will say they have mail, from the user that left the "EALL" message. The TO: will show the user who is receiving the message with "(ALL)" after their name. The message can only be deleted by the sender or a user with SYSOP access 4. Another name that is valid in the TO: prompt is SYSOP, this will be replaced by the Name of the SYSOP, in user slot 1 5. Next prompt is the Subject of the message, if the user just hits return it will exit out of the enter message 6. The bbs will now ask if the message is to be readable only by the receiver of the message or it will be public. 7. Now the user has entered the message editor. 8. Tabs now work in the editor, they are indicated by a '|' in the header. 9. Ctrl-X in the message editor will delete the current line. 10. If you hit a return on a blank line you will exit the edit to the edit command prompt. 11. The options are: 1. A)bort - Abort entering the message 2. C)ont - Continue entering the message, this option will print the last line with text and put the cursor at the end of the line. 3. D)elete - Allows a user to delete a specific line. 4. E)dit - Allows the user to change text within a line. 5. F)ile - Allows a user with access 240+ to attach a file to download to the message. This option will ask for the filename to attach to the message and if you wanted the file deleted with the message as its deleted. 6. L)ist - List the message to the screen. 7. S)ave - Saves the message. <NO_DEF> "T" Touch Message-----V0.26-0.27 <NO_DEF> "U" <NO_DEF> "E" Edit Message...... [ F ] - File Listings: ~~~~~~~~~~~~~ This command allows the user get Full directory listings of the catalogs maintained by the BBS. As mentioned before, this is specified in the BBS:CONFNAME/NDIRS file. 1. If the number of directories in the conference is zero or NDIRS is unavailable, then the bbs will display "No files available in this conference." and drop the user back to the main prompt. 2. Displays the file BBS:CONF/FILEHELP.txt(.gr) only if all the options were not specified on the command line 3. It will then ask for the directory to list including the 'H'old directory. The hold directory can only be used by a user with access greater than 200. 4. The specified directory will be displayed and will pause if the NS hasn't already been specified, at the users lines per screen point. 5. On the pause prompt, you can select 'F' for flaging files [ G ] - Goodbye (LOGOFF): ~~~~~~~~~~~~~~~~ This option is used to end the current session with the host system by the remote user. When the user hits 'G', the bbs performs several clean-up functions. 1. First checks to see if there was a ZooMail that hasn't been downloaded, if there was it would ask if the user wanted to leave anyway. 2. The system then checks to see if there were any partial uploads that the user hasn't finished sending yet. If so then it would let the user know and ask if he wanted to leave anyway. If the user didn't want to leave, then the bbs would ask if the user wanted to view the files. If the user did want to view them, then the bbs would go into the resume routine showing the user the filename and filesize, then ask if he wanted to resume on that peticular file. If not then the bbs would ask if the user wanted to delete the file. If the user didn't want to delete the file then the bbs would go to the next file that was to be resumed. 3. If the user hadn't specified the 'Q' at the ANSI color prompt, or the SUPPRESS_QLOGON is given the bbs would display the file: BBS:NODE{x}/LOGOFF.txt(.gr) [ H ] - Help: ~~~~ This command displays the on-line help text file for the user to refer to. At this command, the bbs looks for and displays the file : BBS:BBSHELP.TXT(.GR) and if not found will say that No help is currently available. [ I ] - Information Conference: ~~~~~~~~~~~~~~~~~~~~~~ This Command lets you get into a BBSInfo Conference where the user can see some bulletins like Top Uploader/Downloader/Caller etc. To enable this function for a specificed Level for User you must change the Accessnumber in the DEF.BBS Extended Config for AmiExpress 1. First this Command the bbs displays the Top CPS Downloader and the Top CPS Uploader... 2. Then the bbs checks if the user who locked in has the same or higher Security Level as in the DEF.BBS Extended Config which will be decribed later on. [ J ] - Join Conference: ~~~~~~~~~~~~~~~ This command is used to switch from the current conference to another conference that the user has access privilege to. The BBS looks for the file BBS:NODE{x}/JOINCONF{SEC}.TXT(.GR) and tries to display it. If not found, it will print a message informing the user that the file is missing. Then, prompts the user to enter the number of the conference they wish to join. If the user does not have access to the requested conference, then the bbs will tell the user that they don't have access to that conference. If the user has access to the requested conference, AmiExpress switches to that conference and checks for mail for the user, and then display any appropriate bulletin files if they exist. If the Option "RELATIVE_CONFERENCES" is turned on in the ACP.STARTUP this will only display the Conferences on which the User have access to. [ M ] - Mode Select: ~~~~~~~~~~~ This command switches between ANSI color output or Plain Monochrome output on the users end. When ansi is on, the bbs tries to display files that have the (.GR) extension by default. The normal plain (.TXT) files are reverted to if (.GR) extensioned files are not found. [ N ] - New Files Since Date: ~~~~~~~~~~~~~~~~~~~~ This command allows the user to list files from specified date onwards or from the last time they called the system. In other words, with this command, users can see what the system has to offer in terms of files since their last call. 1. If the number of directories in the conference is zero then the bbs will display "No files available in this conference." and drop the user back to the main prompt. 2. It will then ask for the date they want to list from. The last date they were on will be the default, this is selected by just hitting return alone. Entering the date to list from must be done as MM-DD-YY. 3. Next the bbs asks for the directory to search thru. An 'A' can be used to list all directories, also 'U' can be specified for the upload directory. And H for the hold directory. The hold directory can only be used by a user with access greater than 200. 4. The Pause prompt works the same as described in the file listing section. <VERIFY>4b "N S G" <V0.39j> GLOBAL "NewFiles" Scanning <VERIFY>5. "N T U" <V0.17> Added is support for Newscans. [ O ] - Operator Page: ~~~~~~~~~~~~~ This command is used by the remote user to call the system operator for on-line chat. 1. if the User is calling up the system operator for the first time on the current session, the users name field be changed to a red color when 3 bitplanes are active, and will have star preceding his name if the bbs was booted in 1 bitplane. Also, if the iconfied window is active, the name filed there will also be highlighted a different color. In this way, a sysop can see if the user on-line has requested to chat. 2. If the F7 Chat toggle flag is not set to allow paging then the bbs says: "Sorry, The SYSOP, is not around right now You can use 'C' to leave a comment." 3. If the chat toggle flag is set to allow paging, then the bbs adds to BBS:NODE{x}/CALLERSLOG that the user paged Then displays "Paging SYSOP (CTRL-C to Abort). ." followed by bells and more dots. 4. If you, the SYSOP, wanted to chat with the user you would Hit F1 to enter chat, then AmiExpress looks for the file BBS:NODE{x}/STARTCHAT.TXT(.GR), and if found displays it to the user. This can be a simple greeting to the user. If this file is not found, then the standard sysop chat active message is sent to the screen. The same F1 will exit chat when you are finished and the bbs will display the File BBS:NODE{x}/ENDCHAT.TXT(.GR). During chat, if ANSI mode is selected, your text will be a different color than the user ones. <NO_DEF> "OL" V0.25-0.26 <NO_DEF> "OLM" V0.25-0.26 ^Included new Commandline Option: OL - OLM to a Port ^This OLM will even send a Message to the other Port if the User is ^Up or Downloading, Using a Door or is reading a Message. If it is ^that Case it will send the Message AFTER he is finished with ^whatever he is just doing. [ R ] - Read Mail: ~~~~~~~~~ This command is used to access the on-line mailing system to read mail either to the user or for all users. It is also used when a certain message will be replied to. 1. First the bbs shows the read prompt A>gain D>elete F>ile R>eply S>earch Q>uit <CR>=Next ( a+b )? (1). A>gain, displays the message currently on again. (specified by the 'a' in the above line) (2). D>elete, allows the user to delete a message only if he left the message or the message is to him. Also a user with access of 210+ can delete any mail. (3). F>ile, will test if there is any Attached File to download. (4). R>eply, allowes the user to reply to the current message. The bbs will place the user on the SUBJECT: field with the previous subject and place the cursor on the end of the line. If the user wants to change the subject he can delete over the existing subject and enter a new one, or hitting return will keep the old subject. After this, the bbs will ask if the reply should be private, and by default this is set to No. Next, the bbs will ask whether to quote the current message in the reply, again the default is No. if the user selected Yes to quote the message, the entire message will be re-displayed and the bbs will prompt the user with the following: Enter Startline,Endline or (*=ALL, A=Abort): Where the user would have to type either a '*' to quote the whole message specify start and end lines seperated by a comma. Then the user would be put in the on-line message editor to enter his message. Commands for the editor work in much the same way as the Enter Message command. For more information, please re-read the ENTER MESSAGE Command. (5). <CR=Next>, let you continue search for new messages (6). "EH" - This allows the sysop to edit a messages Header. You can change who the msg is to, from, the subject and whether it is to be a private message. <ERRATA>.......have to explain how I configure to use PlusED V2.0 (7) "E" - Edit Message. This can use both S!X internal and a specified EXTERNAL EDITOR. (8) "U" - This allows you to IMMEDIATELY go to the ACCOUNT EDITOR while reading messages from any user. Note that it calls up the account of the person who sent (FROM:) <NO_DEF> "A" ABORT <NO_DEF> "T" Touch Message----- [ S ] - Status of On-Line User: ~~~~~~~~~~~~~~~~~~~~~~ This command simply reports the users' current information pertaining to his account. This is in the form of: (123456789) Conf Access: XXXXXXXXX Caller Num.: 2049 Lst Date On: 05-14-91 Security Lv: 30 # Times On : 579 Ratio DL/UL: Disabled # Downloads: 0 # Uploads : 0 Bytes DL'd : 0 Bytes UL'd : 1 Online Baud: 16800 Rate CPS UP: 0 Rate CPS DN: 0 Screen Clr: NO Bytes Avail: 0 If the option "RELATIVE_CONFERENCE" is turned on in the ACP.STARTUP the Conference Access Information is turned off. <NO_DEF> "SS" V0.24-0.25 [ T ] - Time, at the system site: ~~~~~~~~~~~~~~~~~~~~~~~~ This command reports back to the user what the internal battery backed up clock at the bbs site is set at. Local time/date stamp function. [ U ] - Upload File(s): ~~~~~~~~~~~~~~ This command puts the bbs in the file receive mode, where the remote user can send files to the system. 1. The bbs first checks to see if there are file directories to be uploaded to, by looking at BBS:CONF/NDIRS. If this file is unavailable or reports zero, the user is returned back to the MAIN MENU PROMPT after a message stating "No files available in this conference." 2. If a file called UPLOADMSG.txt(.gr) exists in BBSTEXTS or the CONF() the bbs displays that to the user. 3. The bbs now displays the Top Upload Speeders of the System.... 4. The bbs now calculates free disk space, the first number displayed, is the amount of free space on all the drives listed in BBS:AMI_DRIVES DH0: DH1: DH2: DH4: <-- DH3: is not used for the bbs at all therefore it is not in the list. ***NOTE*** In setting up S!X you must create the file called BBS:AMI_DRIVES. a. UPDATE---Version 0.39y9 If BBS:Ami_Drives is non-existant it will now assume all Uploads/Downloads are only on the drive where the BBS is located! Only drives that contain download files for the bbs should be included, this way the user knows how much free space is left on the total system. The second number displayed is the amount of free space only in the BBS:CONF/UPLOAD directory. This is so the bbs and the user know exactly how much space is available to receive uploads until the sysop does some maintance. Currently the bbs is content to allow uploads until the free space in BBS:CONF/UPLOAD is less than 2000000 bytes 5. At this point the bbs calls the resume routine to check if there are any files to resume on, this works the same as explained under the 'G'oodbye command. 6. The bbs will then ask the user to enter the filenames of the files he will be uploading, or he can press return alone to have zmodem tell the bbs the names. Specifing an 'A' will abort out of upload altogether and drop the user back to the main prompt. 7. If the user enters the filenames, the bbs will check to make sure they don't already exist in the conference, if not the bbs will ask him to enter the description for each file. You can choose in your Extended Config how many lines the User can use for his discription. Entering a blank line to end the description. 8. Next the bbs will display: (Enter) to Start, (G)oodbye after transfer, (A)bort? this works the same as specified in the download routines. 9. At this point if the user has not been added to the end of BBS:NODE{x}/UDLOG he will be. 10. If the Upload will now be started the bbs will check in the file you specified for the NODE* FilesNotAllowed option in ACP if this file is not allowed to be uploaded and will skip the upload. 11. If the Upload finished correctly the bbs checks if the User uploadcps was higher than the last Top Speeder User... if it is higher the bbs will display a little text that the user is now the fastest UploadCps User and then write it down.. 12. The bbs displays the stats from the transfer for all the files. 13. The users time is credited for the uploads. 14. Next the bbs goes thru the files sent and checks to see if the name is longer than 12 characters, if so the bbs asks the user to rename the file. 15. The bbs then checks to see if the user has already given the descriptions for the file, if so it posts it accordingly. 16. If the user has not already given the description the bbs asks for the description for the file. Again giving 8 lines for the description. 17. If the user gets disconnected while entering the description the bbs will put "LOSS CARRIER" for the description. and place the file in the BBS:CONF/LCFILES directory along with a <usernumber>.lc file which will contain a list of all the files he will need to enter descriptions for when he calls back. The Re-Enter description process is done at log on with the PartUploads routine. 18. Once the description has been entered the bbs checks if there is a door called "FILECHECK" in the SYS.CMD customcommand file and if it exists it will be executed and the normal "FCHECK" will be skipped. Here you can use a internal door for checking your files. If the door doesn`t exists express will check if there is a file extension. (a file extension is usually on 3 characters preceeded by a '.'.) Express now compares the extension if any with files of the same extension name in the BBS:FCheck directory. Files in the Fcheck directory specify that you are using external file checkers. The format for each file is as follows ----cut here---- <Checker Name> <option> <---- if no option you must use the space. <error text> <error text> <---- This text should reflect what ----cut here---- the external checker will display in the event of a bad file. ie: ----cut here---- DMS Test Fatal Error Invalid ----cut here---- ^ | ------ Save this as BBS:Fcheck/DMS If no external checker exists for the file then it proceeds to step B. 19. If the archive is checked and it passes the bbs puts a 'P' between the filename and filesize in the listing. 20. If the archive is checked and if found bad then the bbs puts a 'F' between the filename and filesize in the listing. 21. If the file is not one of the above checkable file types then the bbs puts a 'N' between the filename and the filesize in the listing. 22. Now the bbs will post the file in a listings area. If the user specified a '/' at the beginning of the description for the file, or the file failed archive check, or the user got disconnected then the bbs posts the file to the end of BBS:CONF/HOLD/HELD If the archive passed or wasn't checkable and the user didn't specify a '/' at the beginning of the description then the bbs will post the file to the end of BBS:CONF/DIR{u} where u is the upload directory (or the highest directory available) 23. If when the bbs goes to move the file, like to the hold directory and there is already a file in the hold with the same name, the bbs will add a '_' to the end of the filename until it can rename it to there. 24. Once all the file are exhausted the bbs checks to make sure there aren't any free floating files in the BBS:NODEx/PLAYPEN directory, if there are the bbs moves the files to BBS:CONF/PARTUPLOAD as partially uploaded files from the current user online. [ V ] - View a Text File: ~~~~~~~~~~~~~~~~ This command allows the user to view the contents of a TEXT file located in the BBS:CONFNAME/UPLOAD directory. For Co-Sysop's with 240+ security, TEXT files can be viewed from any valid system path. 1. The bbs first checks to see if there are file dirs in that conf. by looking at BBS:CONF/NDIRS. if this file is unavailable or reports zero, the user is returned back to the MAIN MENU PROMPT after a message stating "No files available in this conference." 2. The bbs then asks the user for the filename to view. 3. If the users access is greater than 200 and he specified 'VS' instead of just 'V' then allow the filename to include the path. The sysop view is noted at the end of BBS:NODE{x}/CALLERSLOG what file was viewed. 4. The bbs then displays the file as long as the characters in the file are < 128 in value. If a character is greater than 127 then the bbs says "This file is not a text file." and drops back to the main prompt. NOTE: If a file has a comment of RESTRICTED then the user will not be able to view the file. If an attempt was made then the users name will be annotated in the BBS:NODE{x}/CallersLog [ W ] - Write User Parameters: ~~~~~~~~~~~~~~~~~~~~~ This command allows the user to change some personal items pertaining to his account on the system. When called, this command brings up the following: 1. Name : Mike Thomas 2. From : Dover, NH 3. Phone : 603-555-1212 4. Password : ?????? 5. NumLines : 23 6. Computer : Amiga 2000/GVP030 7. Scrn Clr : No 8. ANSI : Yes 9. QUICKLOGON : DISABLED A. Logon WHO : YES B. MailScan : YES C. QuietNode : DISABLED D. Language : English E. Protocol : Z-Modem F. Reply Text : ON G. Msg Sentby: : "Creator" of the ORIGINAL AmiExpress BBS Which to change <CR>= QUIT ? At this prompt, the user can select which item to change, or hit return alone to exit from this routine. 1. All of the fields can be ENABLED/DISABLED by the SYSOP in various fields of your ACP.STARTUP, so read the chapter on configuring ACP.STARTUP completely 2. Several fields are controlled by BBS:SYSTEM/ commands such as Logon WHO, QUICKLOGON. 3. Language can be changed using the appropriate catalog, and protocol can now be changed having HydraCOM, S-Modem and future protocols in BBS:SYSTEM MailSCAN now shows % done, type of messages you will receive, Subject/Sender/# of all message to you, and whether they are EALL/Private/Public as of V0.39q9. [WHO] - Node Information: ~~~~~~~~~~~~~~~~ This command shows the user which users are online on the other nodes and what they are doing actually. If ya choose QUIETNODE for a specified node, this node will be skipped in displaying it at this information. [ X ] - Expert Mode Toggle: ~~~~~~~~~~~~~~~~~~ This command allows the user to switch between eXpert and Novice mode where expert mode will not display the menu unless a '?' is specified at the command line and Novice will redisplay the menu after every command issued and completed. [ Z ] - Zippy Search: ~~~~~~~~~~~~ This command allows the user to scan thru all the BBS:CONFNAME/DIR{x} files for a match for a specified string. When it finds a match, it displays the whole filespec including the description. If the BBS:CONFNAME/NDIRS file reports zero or does not exist, then zippy search will not be functional. [ ZOOM ] - Zoom Mail: ~~~~~~~~ Zoom mail has been reinstalled into Ami-Express and now relies on current compression schemes provided by modem manufacturers instead of Zoo, as zoo has a tendency to crash the amiga in certain instances. ZOOM will compile all the user's unread mail from ALL accessable conferences into a freely downloadable file that will be auto-matically added to the flaglist for downloading. This sums up the REGULAR USER COMMANDS of Ami-Express BBS. The following section deals with advanced configuration methods for optimum performance from the BBS software. Included in the next section also are example scripts for many different external functions and doors. 12.1. CHAPTER 12A S!X Online Help System CREATION and USAGE ===================================================== ************************************************************** CHAPTER 12.1 S!X "Online Help System" CREATION and USAGE ************************************************************** <NO_DEF> Explain the "^" command and BBS:HELP to create your own complete "online help library". 13. CHAPTER 13 S!X Custom Commands File Setup/Usage =============================================== ************************************************************** CHAPTER 13 S!X "Custom Commands" File Setup/Usage ************************************************************** Custom Commands is the key to making the new Modules work on AmiExpress All you have to do is specify the Module name you would like users to use, in a file called BBS.CMD or CONF{x}.CMD, this file can go in the BBS:Commands directory. If the Door is listed in the CONF{x}.CMD or BBS.CMD file then the door will be executed. The format is as follows: ~~~~~~~~~~~~~~~~~~~~~~~~ __________ COMMAND TO ENTER MODULE | _______ MODULE TYPE ( SEE BELOW FOR EXPLAINATION OF TYPES ALLOWED) | | ________ MULTI or SINGLE NODE MODULE | || _________ SECURITY ACCESS LEVEL | ||| ________MODULE LOCATION AND FILENAME | ||| | | ||| | v vvv v BB XS020BBS:BulletinBoard Bulletins XM030BBS:BulletinBoard CoSysop XS040WORK:CoSysop/CoSysop Test RM050bbs:rexx/test.rexx spawn RS001pgdoors:hacker/misc/rxx.maint hacker RM100pgdoors:hacker/hacker.strip motel RS090pgdoors:motel/motel! NOTE: That this is a formatted file, The module type must be in position 11 and the path and filename of the module must be in position 16. OPTIONAL RETARD COMMANDS FORMAT ____________ TRUNCATE COMMAND COMPARISON. | __________ COMMAND TO ENTER MODULE | | _______ MODULE TYPE ( SEE BELOW FOR EXPLAINATION OF TYPES ALLOWED | | | ________ MULTI or SINGLE NODE MODULE | | || _________ SECURITY ACCESS LEVEL | | ||| ________MODULE LOCATION AND FILENAME | | ||| | | | ||| | v v vvv v *BB XS020BBS:BulletinBoard *Test RM050bbs:rexx/test.rexx MODULE TYPE - Module type may be any of the following: X,R,P X = This means the module is an AmiExpress module. R = This means the module is an Arexx module. Which means RexxDoor will be called to execute it. P = This means the module is a Traditional module, so the BBS will launch ParaDoor to execute this module. NOTE: RETARD COMMANDS- Could not think of a better name for it but the '*' at the beginning of the module name indicates that if the first part of the command from the menu prompt matches the module name then it will assume you made a mistake when typing the command, Otherwise it would not find the module name and try to execute an internal command in the BBS. IE: Looking above at the 'Test' Module if we did not have the '*' then a user could accidently type 'Testit'. If this did occur then express would not be able to locate the module named TestIt and therefore execute the internal 'T' command which would result in the user getting the system time instead of the test. Using the RETARD command is a good why of overriding internal BBS commands with commands of your own. 13.1. CHAPTER 13.1 (DizExtract) Automatic File Description System =========================================================== ************************************************************** CHAPTER 13.1 (DizExtract) Automatic File Description System ************************************************************** S!X includes the capability to using a new system of automatic file descriptions called: File_ID.Diz support. To utilize this new system, you must have several programs such as LHA, DMS, LZX, SHR and other compression systems in your appropriate paths. In addition you will need a few special "3rd party utilities", such as DMSDizExtract and others. There are several variations of these; we will leave each SYSOP chose his favorite versions. 1. FIRST create a Directory called BBS:DizExtract 2. SECOND create ASCII text files inside BBS:DizExtract for each type of compressed files you wish to use the File_ID.Diz feature. That is you will create files with names such as: BBS:DizExtract/LHA.... for LHA Files BBS:DizExtract/DMS.... for LZH Files 3. THIRD you must edit each of these files with your favorite text editor, providing the following information: 1st Line: NAME & PATH to archive extraction program. 2nd Line: "Archivers" command syntax for "extracting" information. NOTE: If this archive format requires no <args> for extraction place a SPACE [ ] in LINE 2. **DO NOT* just hit a line return [CR]......there must be a SPACE [ ] just as is required to use S!X FCheck features. 3rd Line: Place this archive types "Text String" here. It is common that many "DIZ UTILS" do not require a special command here, so a notice such as: Finished Done will suffice. However some "3rd party utils" do require special strings, so read the docs that came with that particular S!X DIZ utility. EXAMPLES: DMS LHA GIF ZIP parachange LHA GifDesc c:execute dmsdiz x x e bbs:DizExtract/Unzip_Diz THANX Done Finished Completed 13.2. CHAPTER 13.2 Using New BBS:Systems Commands and Directory ========================================================== ************************************************************** CHAPTER 13.2 Using New BBS:Systems Commands and Directory ************************************************************** Very early in S!X's development, we decided that the system should be: 1. More flexible....allowing many 'hard-coded' S!X functions to be moved to EXTERNAL utilities which would allow other to program/update current or new functions into S!X BBS. 2. Speed/Code Size..this allowed S!X's "Express" & "Acp" to be a central 'engine', but allow several other executable programs to handle tasks. It keeps S!X code size lower, speeds processes (akin to the whole idea of multi-tasking where "Express" and "Acp" are the CPU processor). 3. **NOTE ME** All BBS:SYSTEM/ programs MUST be "XIM", since no operations are performed nor addressable via BBS:COMMANDS/bbs.cmd, BBS:Conf(x).cmd, nor normally via BBS:COMMANDS/sys.cmd ( There 'may be?' cases where BBS:SYSTEM/ commands are ) ( supported via BBS:COMMANDS/sys.cmd due to modifing the ) ( InternalCommand() function of S!X to search also in ) ( BBS:COMMANDS/sys.cmd as well as BBS:SYSTEM/.....you will ) ( need to "field test" and read each util's documentation ) ( carefully as to installation and <args> it supports. Several commands exist for the BBS:System directory. Several are included/required for basic operation of S!X; many others are optional and provided by either S!X Development or 3rd party programmers. Unlike custom commands ( "Doors" and your bbs.cmd file) these can not be directly entered at any prompt. Rather they are activated/controlled via special ~MCI scripts, BBS:Commands/sys.cmd file, and other special texts you can create to modify/control your BBS's operations. Due to the many avaiable alternatives, I will hereing list those commands known to S!X as sys.cmd.......and briefly outline what each can do. ANSI ---> Replaces the "ANSI Yes/No" question at LOGON. ARCCHECK ---> This allows using a special external checker in BBS:System. Uses MM_MAINLINE to get Path/<name> and DT_GOODFILE to return values. BGCHECK ---> Allow checking of files "in the background, which currently (V0.39u6) was Noisy Belch's ßeta version of BGchecker. DESCRIPTOR ---> Replaces the internal "File Description Editor" with the appropriate XIM Module you chose. (**NOTE** I've never seen a really good one yet ....so if anyone has one, send it to "Doc") DUPECHECK ---> This automatically checks Dir(s) for "duplicate files". It could also be programmed to check Path() or ULpath() specified in a Conf(). 1. If this Door returns a FAILED_TEST (like most Filecheckers if test NOT successful), it will skip the remainder of checking and move the file to your HOLD along with the description of the file. EDITOR ---> V0.39u3 Belch EDITOR V0.4ßeta. Now S!X offers a FULLSCREEN EDITOR option in BBS:system which we are testing. Obtain a copy of this program and its documentation to learn of all its features. EXAMINE ---> Use this to take advantage of a File_ID Door. (Note: Internal One has been taken out a few Days ago, going to provide a new EXTERNAL One Made by the "Master" himself.. (errr) EXAMINE1-9 ---> Just incase you`d like to run more than one EXAMINE Door (e.g.: a Door to print out the Date of the File_Id.Diz File into the File Listing (DizDater)) a. Right after running the BBS:SYSTEM/EXAMINE Door, S!X will search for EXAMINE(1-9) and run them consecutively if found. **BE CERTAIN THEY ARE NUMBERED CONSECUTIVELY to use this feature. Example: BBS:SYSTEM/Examine (***EXISTS***) BBS:System/Examine1 (***EXISTS***) BBS:System/Examine2 (***EXISTS***) BBS:System/Examine3 (***EXISTS***) b. In the above case, S!X first runs "Examine", and then runs Examine(1-3) consecutively. FILECHECK ---> This automatically checks new "Uploads" FILEID ---> This is a TOTALLY "EXTERNAL" File_ID.Diz extracting Door you might use to extract your file descriptions. FILEPROC ---> Detects files in Conf()/LCfiles older than (xx) days and prompts User(s) if they can enter a description. <ERRATA> ......think in "newer S!X" this can also be named ......FILEPROCESSOR, and can be configed to will ......ask User(s) to identify any file in LCfiles ......without waiting (xx) days or for the User ......who U/Led it to describe. for integrity. <NO_DEF> FRONTEND ---> Could be used to replace the {PortStatus()} in front of every LOGON. <VERIFY> MENU ---> ***RESERVED*** for future use <NO_DEF> MOVEFILE ---> ***RESERVED*** for future use NEWFILES ---> Replaces S!X's "N" Menu Function. PAGER ---> Replaces the internal Sysop Page (must be a FULL replacement, not a Sysop Page FrontEnd) PWCHECK ---> Replaces S!X's internal Password Checking Routine. 1. Note this function is used with /X V3.-V4x to covert /X USER.DATA to S!X format; everyone should have this small ASM routine which was programmed by Chris (Calypso), S!X Development PWFAIL ---> Runs a "Door" if user has excessive password fails, i.e. Can send message to SYSOP (MsgBase/Page/Logs) <NO_DEF> SCANMAIL ---> ***RESERVED*** for future usage <NO_DEF> SHOWFILE ---> ***RESERVED*** for future usage STATUS ---> Replacement for the Status Display. Will be executed right after the User logged on in place of the old "Status Display" routine. SMODEM ---> Place the SMODEM executable in your BBS:System for use of the S-Modem PROTOCOL. A new field was added to the User's "W" command to select this protocol. SYSTEMPW ---> Replaces the System Password Prompt (including the Private Text) <VERIFY> UPDESC ---> **RESERVED** for future usage USERFRONT ---> Using this Door you can TOTALLY replace the S!X logic sequence where S!X asks for the user NAME/PASSWORD. This door is akin to the method which can be utilized with MS_DOS PC-Board. WHO ---> Replaces the internal WHO Command. ZIPPY ---> Replaces S!X's "Z" Menu Function 13.3. CHAPTER 13.3 Using Internal Commands File with S!X ================================================== ************************************************************** CHAPTER 13.3 Using "Internal Commands" File with S!X ************************************************************** You've now read about the "bbs.cmd" file which controls commands your users generally have access to use and "sys.cmd" which control certain internal funcions such as filechecking. For completeness there is a third type called "Internal Commands" which uses a file named: BBS:Commands/int.cmd The syntax is equivalent to that of your "BBS.CMD" file, i.e. /- Cut here -\ TA XM001Doors:TestArchives/TA VA XM001Doors:ViewArchives/VA /- Cut here -\ Using "int.cmd" file makes S!X treat this external program as if it were the INTERNALLY HARD-CODED into S!X itself. The logic is that these become your "DEFAULT COMMANDS"....and are so specified as such cleared in this file. 1. This will avoid confusion with the "bbs.cmd" file, which is more clearly used for those special interest doors (i.e. Games/Trivia/Humor) you might install. 2. ***SEE BBS:SYSTEM*** As we work with S!X Programmers and 3rd party programmers which allow us permission to "use their work" they will be moved to the BBS:SYSTEM dir and appropriate new BBS:SYSTEM "CommandNames" (i.e. PWFAIL ANSI EDITOR) will be added that you can use by placing the program directly in BBS:SYSTEM. That is: If you see an appropriate <DEFAULT NAME> reading the chapter on BBS:SYSTEM, you no longer need to use the BBS:Commands/int.cmd file. We've tested and approved this as a "standard feature" we will support in all S!X versions. 3. Those new SYSTEM type commands we/you are evaluating can be made "internal" until we decide YES/NO to creating the appropriate new FileNames() for BBS:SYSTEM. Should we chose not to use a program you really like, then you can still use it as an "Internal DEFAULT" by using this new INT.CMD file in your BBS:Command Directory. 14. CHAPTER 14 (MCI) Macro Command Interpreter Commands/Usage ========================================================= ************************************************************** CHAPTER 14 (MCI) Macro Command Interpreter Commands/Usage ************************************************************** Any text file may contain imbedded control sequences which will send out variable text or cause certain things to happen. IN USING THESE SEQUENCES: 1. ALL COMMANDS ARE "Case Sensitive"!!!! 2. ~MCI Commands are always terminated with an '|' or ' ' !!!!! EXAMPLE: BBS:BBSTexts/logon.txt ~ ~CC_ANNLOGON| ~SS_bbs:screens/logon1.txt| ~SP| ~SS_bbs:screens/INFO.txt| ~SP| ~CC_SCAN| EXAMPLE: A little msg. in a COnf()/Msgbase Having a line in a text file that contains: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~N , I hope everything is going well in ~L . (NOTE " ") Might show: ~~~~~~~~~~ Gregg Green, I hope everything is going well in Ohio. MCI - Introducer: ~~~~~~~~~~~~~~~~ ~ This is the MCI introducer, this must be at the beginning of each text file by itself inorder for Express to switch to the MCI interpreter for displaying the text file. MCI - User Specification: ~~~~~~~~~~~~~~~~~~~~~~~~ ~N User Name ~UL User Location ~P User PasswordP ~# User Phone ~TC Total User Calls ~LC User Last Call to the system ~M User Message Posted ~A User Access Level ~S User Slot Number ~CA User Conf. Access **** NOTE CHANGED FROM X **** ~BR User BaudRate ~HW User Computer Equipment ~TL User Inital Time Limit at logon in Minutes ~TR User Number of Mins Remaning today ~UB User Bytes Uploaded ~DB User Bytes Downloaded ~FU User Files Uploaded ~FD User Files Downloaded ~BD User Byte Download Limit ~LG User Logged On-Node ~Dx Change the MCI command terminator. i.e: ~D.| will change the '|' to '.' ~cx Change foreground ansi color to anything from 0-f. ~bx Change background ansi color to anything from 0-f. ~h Back Space ~q Change to default ANSI mode. ~f Clear Screen. ~nx Newlines where x is the number of them you would like ~~ This indicates you wish the ~ symbol to apprear, you can have as many of them as you like after the first ~ to display them (NOTE: no ',' on this command) ~xn Goto X position on screen. ie: ~x10 ~yn Goto Y position on screen. ie: ~y10 NOTE: The above commands allow you to specify a width identifier before the action test.. ie: ~10N only displays first 10 letters of username. MCI - System Specification: ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~SC System Total calls <VERIFY> ~O Number of the other users current Online (not implemented...) ~CT Show current Time ~DT Show current Date MCI - Extra Specification: ~~~~~~~~~~~~~~~~~~~~~~~~~ <VERIFY> ~CL Will generate a list of all your Conf() for joinconf.txt <VERIFY> ~CD Disable CTRL-C during showfile <VERIFY> ~CE, Enable CTRL+C during showfile....(not implemented) <NODEF> ~HMI Version V0.39s1 Drops Carrier if users viewing a file and S!X encounters this sequence. ~CR Will wait for any key to be pressed. ~CR_Prompt Will wait for and prompt the user to press any key. ie: ~CR_PressAnyKey ~SP Will do a standard pause, this is useful to put in between each ~SS command. ~SR_Format Will show a random txt file based on the file format given and the max number of txt files given. ie: ~10SR_BBS:Screens/Logon This will tell express to choose a number between 1-10 and use that number to show the corosponding txt file: Say the BBS choose number 2, then express would attempt to show the file: BBS:Screens/Logon2.txt This features replaces the auto logon & logoff random- ization routines found in earlier versions of express. ~SS_Name Show <name> file. This file may also be an MCI file. WARNING: This command could cause a serious loop problem if you tell it to show the same file you are viewing. WARNING: You may need to increase STACK if you nest to many of these files. NOTE: If this command is accessed via the message base or the View or ViewSysop commands, then the file you are going to view has to have a file comment of 'Allowed' or '{xxx}Allowed' {xxx} specifies security level or above ie: {050}Allowed, idicates that only those over or equal to access level of 50 are allowed to view the file. ~SZ_Path+Filename <VERIFY WORKS> With this command you can do a ZModem Send D/L of the file specified behind the MCI command. <VERIFY> 1. This is **NOT POSSIBLE** in MsgBases for security reasons against "hacking".....will think about method <VERIFY> 2. It is **NOT POSSIBLE** to use the ~SS_Path+Filename| MCI command when using SYS.CMD Doors to display either TEXT =or= BINARY. This should prevent the "hacking" attempts ( V0.34 on a suggestion by "Doc") <ERRATA> 3. Steve is working on a way to "get around this" with PRIVATE MAIL........... ~CC_Name Launch a door 'Name' is the door's name. ie: ~CC_WHO will look in SYS.CMD, BBS.CMD and CONF.CMD customcommands which must be located in the BBS:Commands directory. <VERIFY> ~SE(x) Turn OFF Output of screen if user has not access to conf.(x)...(NOT IMPLEMENTED) <VERIFY> ~SD(x)| Turn Output BACK on that was disabled with previous command...(NOT IMPLEMENTED) 14.1. CHAPTER 14.1 Using BBSTexts Dir to Display Texts/Screens/Ansi ============================================================= ************************************************************** CHAPTER 14.1 Using BBSTexts Dir to Display Texts/Screens/Ansi ************************************************************** As of S!X V0.18, we centralized many of what commonly are know as "Menus" or "Conference Texts". We found that /X (AmiExpress) and other BBSs required having numerous redundant copies of the same text in many different locations, and we decided to reduce this redundency by using a central directory for these. This also made creating a new "Conference" much easier; we no longer had to duplicate many different texts as they all could be in a central area. HOWEVER......we saved the ability for each SYSOP to still have these texts in each "Conference" if each area actually had different information. 1. S!X searches for the <text> in the "Current Conf()", then searches in BBStexts for a centralized copy used with all your Conf(). This gives you the maximum flexibility. LET ME REPEAT......it first searches in your Node() or Conf() files for the given text, and if not found searches in BBSTexts. We did it this way to give you maximum flexibility how you configure your S!X, or the ability to show different texts in different Node() or Conf(). 2. The format of each textfile is: <NAME>[accesslevel].txt[.gr] where: NAME = name of the text ACCESS LEVEL = (Optional) the access level needed for this text to be displayed. If *NONE* is specified then all users can see this text. TYPE = This tells S!X what type of text format, and therefore how to display this text. .txt = either plain BLACK/WHITE or COLOR texts. If you use COLOR, then the user would have to use the "M" menu function to avoid seeing the text in a color format .txt.gr = COLOR CODED. This is for those which wish both BLACK/WHITE and COLOR coded texts. .rip = RIP graphics. This is a special gfx/text format which uses the RIPcomm format popular in MS-Dos. If .RIP is not available, it defaults back to your normal .txt format. a. Please note that using both ".txt" and ".txt.gr" is very redundant and **NOT REQUIRED**. The user can turn color display ON/OFF via the standard "M" menu function. So this is an older feature; we keep as a few people do prefer having both text versions. 3. NOTE: a. If <.txt> not shown, you do not need any ending extension such as: .txt .txt.gr for this file. b. <lvl> <baud> are **OPTIONAL**. S!X defaults to using TextName().txt first; if NOT FOUND it then searches for the same TextName<lvl> or TextName<baud>. 4. Changed "Logic Order" of how BBStexts are displayed. Now S!X first searches for .TXT | .RIP | .TXT.GR without any <lvl> or access levels. If not found then it increases the <lvl> and continues searching for a text at that <lvl>. a. As explained above, using .TXT.GR is quite redundant. It was also EXTREMELY REDUNDANT for most systems to have the same text with all these <lvl>s; most folks show the same text to all users with perhaps a "few" exceptions. This change speeds up S!X seaching and displaying of BBSTexts significantly and makes maintaining BBSTexts much simpler. DIRECTORY: BBS:BBSTexts AwaitScreen.txt ---> "Await Logon Screen" is screen you see while waiting for someone to LOGON to a Node(). Used to be hardcoded into S!X but now editable. BBSHelp.txt<lvl> ---> Help screen to show how to use S!X. Usually used in connections with "^" and S!X Online Help Menu Systems. Bull<lvl>.txt ---> Centralized replacement for "General User BULL" Computerlist ---> List of ComputerTypes your BBS supports. Data is saved to USER.DATA for your/their info. DownloadMsg.txt ---> Displays to User upon downloading files from your system to thank him and remind him what value there is using your system. EndChat<lvl>.txt ---> Displays a message to user when "Chat" ended. GuestLogon.txt ---> Displayed to "New Users" without accounts in your USER.DATA to tell them about your BBS. Join.txt ---> Displayed to "New Users" if they say they want access before Application starts. Joined.txt ---> Displayed to "New Users" just after finishing your Application. JoinConf<lvl>.txt---> Displays available Conf(s) on your system. Languages ---> List of Languages (FRENCH/ENGLISH/ETC) supported. a. The Lanugages text can exist in either BBSTexts or BBS:Node() and must have the following format: LINE 1: Number of Languages Used LINE 2-xx: Names of the Langages EXAMPLE: -----cut---- 4 English German French Swedish -----cut---- <ERRATA> b. These languages must exists in _________ and requires using ___________ libraries. Lockout-<lvl>.txt---> LEVELS=0,1,2 Displays text, based on USER.DATA AccessLevel.....then hangs up on user. Logoff<lvl>.txt ---> Displayed to users when they say "GoodBye" Logon<lvl>.txt ---> Displayed to users when they LogOn to system. Logon24hrs.txt ---> Displayed if user exceeds DAILY TIME LIMIT. MailScan-Header.txt-> Displayed to used just before starting a MailScan. MailScan-Tailer.txt-> Displayed to user just after completing a MailScan Menu<lvl>.txt ---> Displays available USER COMMANDS. NamesNotAllowed ---> Create as ASCII text with names of "Users". These names will not be allowed to be used. NewUserPW.txt ---> If not in USER.DATA, user must know this PASSWORD to get access even to apply. NoNewAt<Baud> ---> *LOCKS* "New Users" from applying at given <Baud> and displays text informing them. NoNewUsers ---> Tells "New Users" you are not accepting any applications at this time. <NO_DEF> OnlyOnOnePort.txt---> PhoneCheck ---> If exists, asks last 4 digits of phone #, then checks as "security" against USER.DATA Private.txt ---> Used for "security" normally...displays before asking for your SYSTEM ACCESS "PASSWORD". Script<Baud> ---> This is your "Application" in ~MCI encoded format to ask "New Users" questions. StartChat<lvl>.txt--> Displays screen as you enter "Chat" mode. UploadMsg.txt ---> Displays to user to thank him for uploading to your system. UploadThx.txt ---> You can now display a "Thanks for Upload" message to be displayed after a successful upload. (Can also be in BBS:Conf() as well as BBS:BBSTexts). 14.2. CHAPTER 14.2 USING SPECIAL <FileNames> TO CONTROL NODE(s) ========================================================= ************************************************************** CHAPTER 14.2 USING SPECIAL <FileNames> TO CONTROL NODE(s) ************************************************************** For those running multiple Node(s), it is often advisable to control access, usage, baudrate, or other restricted access. This can be due to several reasons, but generally it is to maximize system usage. S!X allows certain special FILENAMES which will control certain actions. These are: NotThisNode ---> This is a plain ASCII file containing the "exact" USER NAMES of "users" you do not wish using this Node(). If the user's name exists, it will LOCK_OUT access. UsersAllowed ---> This is basically another way around the idea of having only certain users gaining access to a particular Node(). For example, let's assume Node(2) is your only 28.8 node and you wish only users with 28.8 modems to have access. NoHydra ---> If this text exists in any Node(), it will not allow using HydraCOM protocol for U/Ding. (File can be any text such as, "Sorry, HydraCOM PROTOCOL not allowed at this time"). 14.3. CHAPTER 14.3 USING CONF() SPECIFIC COMMANDS/TEXTS/BULLS ======================================================= ************************************************************** CHAPTER 14.3 USING CONF() SPECIFIC COMMANDS/TEXTS/BULLS ************************************************************** 1. S!X CONF() SPECIFIC "Texts" The following "text" files are those which you can specially put in any Conf() to alter the behavior of that Conf(). We have not noted "texts" which now normally appear in BBS:BBSTexts directory, although most can be placed in a specific Conf() to give special displays in a specific Conf(). SEE BBSTexts for a description of the GENERAL TEXTS; (Done to reduce S!X Manual size). ------------------------------------------------------------------------ PASSWORD ---> If you have this text in any Conf(), it will protect both MAINSCAN in the Conf() and entry access. 1. Create a textfile in Conf(s) called PASSWORD 2. In this textfile place your "password" for use of this Conf(s). ****NOTE**** Do not put a [CR] or RETURN at the end of the "password". ------------------------------------------------------------------------ NDIRS ---> Former to S!X V0.39q5 it was REQUIRED to have a file called NDIRS in each Conf(); this is NO LONGER REQUIRED! Now S!X "autoscans" beginning at Dir(1) and continues INFINITELY until reaching the highest DIR(#). 1. Before you had to "Reboot" after creating a new Dir(#) or changing NDIRS; this is no longer required. 2. We STRONGLY SUGGEST keeping the NDIRS files in each Conf() and keeping them accurate as ***MANY UTILITIES OR "DOORS"*** still require or seek this text and its information EXAMPLES: BossNuke TurboNewScan ------------------------------------------------------------------------ PATHS ---> It is now possible to alter "Paths" without rebooting. We have changed S!X logic so that it will look in your PATHS file on each search; that is on "bootup" they are no longer stored in memory but re-evaluated on each request. ------------------------------------------------------------------------ <ERRATA>....this should be "movable to BBS:BBSTexts UPLOADMSG.TXT ---> Displays a message from the system, usually thanking the User for uploading files --------------------------------------------------------------------------- <ERRATA>....this should be "movable to BBS:BBSTexts DOWNLOADMSG.TXT ---> Displays a message after downloading, usually hoping the user enjoys the files, reminding him of his "ratios", or cajoling to also upload. <NO_DEF> Need to add all notes regarding still using Conf().cmd files, Conf()/Bulletins, Conf() texts and similar files for a SPECIFIC CONF()!!! <VERIFY> Conf1.cmd - still in CONF() or in BBS:Commands 15. CHAPTER 15 S!X UTILITY PROGRAMMERS Door SemiPhores ================================================== ************************************************************** CHAPTER 15 S!X UTILITY PROGRAMMERS' Door SemiPhores ************************************************************** <ERRATA> ***NOTE*** The following is a VERY, VERY INCOMPLETE LIST of all the available semiphore. Only in trying to finally piece together the original /X V2.34 manual with the newer S!X manual that I have completed to date, did I finally get this all into any kind of coherent Chapters. Therefore, you will have to look thru both REVISION.DOC and the "Programmer's Packages" for all new semiphores until I can update this completely. At least this gives you a starting point to write your 1st S!X compatable Door routines. A. (AIM) AREXX INTERFACE MODULES The Arexx door interface requires a file called RexxDoor, It must be in located in your command path. This will also require an ASCII file called BBS.CMD or CONF{x}.CMD to be either located in the BBS:Commands directory. The format of this file will be discussed in the next section. RexxDoor will be launched each time an Arexx door is requested. Note: If a CARRIER LOSS is detected or a KeyBoard timeout is detect then an error code of 10 will be sent to the Arexx Script and RexxDoor will orderly close any ports to the BBS and itself from the Arexx Script. Now we want to discusse all the Arexx Commands which can be used to read & write information of the User & the BBS. These Arexx commands are only usefull if you wanna programm some tools for AmiExpress, and for that it is very hard to understand for a guy who never programmed arexx. But now lets go on: NOTE: These are internal and do not pertain to the Module Glue routines for designing doors. B. (TIM) TRADITIONAL INTERFACE MODULES The Traditional interface provides the capability to run "DOORS" designed for other Bulletin Board Systems. This is not to say that it will interpret all "DOORS" but some may work. The traditional interface requires a file called PARADOOR, which is supplied with AmiExpress and must be located in a path that AmiExpress can find. If a CARRIER LOSS is detected or a keyboard timeout is detected, the BBS will notify the Module, but it is up to the Module to do an orderly halt. Most door programmers know how to close their doors properly. AmiExpress automatically launches the PARADOOR so please do not run it yourself. C. (XIM) EXECUTABLE INTERFACE MODULES This is the most "common" doortype, and was the type actually designed for use directly with /X and S!X. Programmers should have a current "Programmer's Door Package" with the appropriate header/include files and a current list of all available semiphores. <ERRATA> 02-22-96....again this is based on original /X V2.34 and has yet to be totally updated to the current S!X V0.39u3 <ERRATA> V0.39i The entire "Script Door Interface" has never been docu- mented to my knowledge anywhere. IT DOES EXIST!!!.... Quoted from Revision.Doc: "Included new Door Type..: S - for SCRIPT. You can now setup Script Doors.. they wont show anything on the User Side but might be helpful to start several Other Things.. whatever...whatever you just want to start a Script to update your Bulletins. Now its easier... D. SCRIPT INTERFACE MODULES .......................see above <ERRATA> <NO_DEF> .....see MISC as not described correctly yet..... E. (IIM) INTERNAL INTERFACE MODULES <NO_DEF> F. SHELL INTERFACE MODULES G. PROGRAMMERS "SEMIPHORES" and STRUCTURES OF "DOORS" 1. STRUCTURE OF (XIM) DOORS _____________ message structure for use with the XIMs | NOTE: RexxDoors are translated to the same v structure via the RexxDoor utility struct JHMessage { struct Message Msg; <----- msg structure char String[200]; <----- info buffer int Data; <----- Read/Write & result indicator int Command; <----- Command sent from door. int NodeID; <----- reserved int LineNum; <----- reserved unsigned long signal; <----- reserved struct Process *task; <----- see BB_GETTASK below } ; PORTNAME: The portname for the XIMs is 'AEDoorPort(n)' Hereing the (n) stands for which NODE() you wish to work with, ie: AEDoorPort1 = Node(1) 2. STRUCTURE FOR "WHO" DOORS struct SinglePort { struct SignalSemaphore semi; struct MinList sl_List; APTR *MultiCom; <-- Pointer to the MultiCom Address (Chatters) UBYTE SemiName[20]; <-- NO IDEA :( int Status; <-- Enviroment Stats. like 03 = IDLE etc. i.e. Tells what user is "doing" char Handle[31]; <-- Users Handle/Name (duh!) char Location[31]; <-- Users Location char Misc1[100]; <-- Stores either FILENAME *OR* the DoorName. char Misc2[100]; <-- Full Filesize of the current file on Transfer int Conf[2]; <-- Number of the Conference the User is in (RELATIVE) long ActualSize; <-- Actual Size of the transferred File (Position) long CPS; <-- Actual CPS of the current transfer long BaudRate; <-- This is new, has the Users BaudRate he logged in with. int QuietPort; <-- If Port is Quiet this is 1 otherwise 0 USHORT UserNumber; <-- <NEW! V0.39p1> Has the User.Slot_Number! Before it was updating the Semaphores on a Quiet Port so its loading in the Value of -2 for the UserisDoing Code. this is now not done anymore instead it`ll fill in the QuietPort Value with an Integer of 1 if its not Quiet its 0 - should give some more possibilities for Who Doors. 3. S!X FUNCTION # AND COMMAND NAMES FOR PROGRAMMERS COMMAND NAME FUNCTION -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ---------------------------------------------------------------------- <FUNCTION #: 0> JH_LI Requests a string of information from the user with a default string. msg->Command = 0 msg->String = default result string msg->Data = Maximum length of response. msg->Data will be set to a -1 if a loss carrier or console timeout occurs, otherwise msg->Data will be 1 msg->String will be the response string from the user. ------------------------------------------------------------------------ <FUNCTION #: 1> JH_REGISTER Registers a door or XIM with the current node. msg->Command = 1 This must be the first command issued to the express node. This increments the number of doors active for the current node. ------------------------------------------------------------------------ <FUNCTION #: 2> JH_SHUTDOWN Tells the node that a door is shutting down, this decreases the number of active doors inidicator , which once at 0, the AEDoorPort will close. msg->Command = 2 msg->Data = N/A ------------------------------------------------------------------------ <FUNCTION #: 3> JH_WRITE Allows you to send a text string to the user. msg->Command = 3 msg->String = text msg->Data = N/A ------------------------------------------------------------------------ <FUNCTION #: 4> JH_SM Allows you to send a text string to the user. msg->Command = 4 msg->String = text msg->Data = 1 or 0 if msg->Data = 1, then a CR/LF combination will be sent. ------------------------------------------------------------------------ <FUNCTION #: 5> JH_PM Allows you to prompt the user for a specified number of characters. msg->Command = 5 msg->String = prompt string msg->Data = maximum response length. if msg->Data = -1, then a loss carrier has occured or a timeout condition has occured, otherwise msg->Data = 1. msg->String will be the user response. ------------------------------------------------------------------------ <FUNCTION #: 6> JH_HK Allows you to get a 1 character respinse from the user. msg->Command = 6 msg->String = text msg->Data = N/A if msg->Data = -1, then a loss carrier has occured or a timeout condition has occured, otherwise msg->Data = 1. msg->String will be the result string. ------------------------------------------------------------------------ <FUNCTION #: 7> JH_SG Allows you to display a text file to the user. msg->Command = 7 msg->String = part file name. msg->Data = N/A ie: msg->String = "BBS:Node1/Bull This would try to display BBS:Node1/Bull.txt(.gr) also takes into account language specifications. This also searches for the access level patterns, ie: Bull10.txt.gr, Bull100.txt.gr ------------------------------------------------------------------------ <(FUNCTION #: 8> JH_SF Allows you to display a text file to the user. msg->Command = 8 msg->String = Complete pathname msg->Data = N/A ie: msg->String = "BBS:Node1/Bull.txt" This would show the file if it exists. ------------------------------------------------------------------------ <FUNCTION #: 9> JH_EF Allows you to use the internal msgbase editor to edit your own files. msg->Command = 9 msg->String = Complete pathname msg->Data = 0 if msg->Data = -1, then a loss carrier has occured or a timeout has occured, otherwise msg->Data will be 1. ------------------------------------------------------------------------ <FUNCTION #: 10> JH_CO Allows you to send text string to the console only. msg->Command = 10 msg->String = text msg->Data = 1 or 0 if msg->Data = 1, then a CR/LF combination will be sent in addition to the text. ------------------------------------------------------------------------ <FUNCTION #: 10> JH_BBSNAME Allows you to retrieve the BBS Name. msg->Command = 11 msg->Data = N/A msg->String will be the BBS name. ------------------------------------------------------------------------ <FUNCTION #: 12> JH_SYSOP Allows you to retrieve the Sysop's Name. msg->Command = 12 msg->Data = N/A msg->String will be the Sysop name. ------------------------------------------------------------------------ <FUNCTION #: 13> JH_FLAGFILE Allows you to add files to the list of flagged files. msg->Command = 13 msg->String = FileName msg->Data = N/A Adds the msg->String to the list of flagged files for downloading purposes, NOTE: The files must be in the download path for this to work. ------------------------------------------------------------------------ <FUNCTION #: 14> JH_SHOWFLAGS Obsolete, DO NOT USE. msg->Command = 14 ------------------------------------------------------------------------ <FUNCTION #: 15> JH_ExtHK Reserved, DO NOT USE. msg->Command = 15 ------------------------------------------------------------------------ <FUNCTION #: 16> JH_SIGBIT Reserved, DO NOT USE. msg->Command = 16 ------------------------------------------------------------------------ <FUNCTION #: 17> JH_FetchKey Reserved, DO NOT USE. msg->Command = 17 ------------------------------------------------------------------------ <FUNCTION #: 100> DT_NAME Allows you to retrieve or change users name/handle msg->Command = 100 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be the name. if msg->Data = 0, then name will be msg->String ------------------------------------------------------------------------ <FUNCTION #: 101> DT_PASSWORD Allows you to retrieve or change users password msg->Command = 101 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be the password. if msg->Data = 0, then the password will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 102> DT_LOCATION Allows you to retrieve or change users location msg->Command = 102 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be the location if msg->Data = 0, then the location will be msg->String ------------------------------------------------------------------------ <FUNCTION #: 103> DT_PHONENUMBER Allows you to retrieve or change users phone number. msg->Command = 103 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be the phonenumber if msg->Data = 0, ten phonenumber will be msg->String ------------------------------------------------------------------------ <FUNCTION #: 104> DT_SLOTNUMBER Allows you to retrieve users slot number msg->Command = 104 msg->Data = 1 if msg->Data = 1, then msg->String will be the slotnumber. ------------------------------------------------------------------------ <FUNCTION #: 105> DT_ACCESSLEVEL Allows you to retrieve or change users access level. msg->Command = 105 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be accesslevel. if msg->Data = 0, then accesslevel will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 106> DT_RATIOTYPE Allows you to retrieve or change users ratiotype msg->Command = 106 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be ratiotype. if msg->Data = 0, then ratiotype will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 107> DT_RATIO Allows you to retrieve or change users ratio msg->Command = 107 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be ratio. if msg->Data = 0, then ratio will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 108> DT_COMPTYPE Allows you to retrieve or change users computertype code msg->Command = 108 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be computertype. if msg->Data = 0, then computertype will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 109> DT_MESSAGESPOSTED Allows you to retrieve or change users messagesposted msg->Command = 109 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be messagesposted. if msg->Data = 0, then messagesposted will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 110> DT_UPLOADS Allows you to retrieve or change number of useruploads. msg->Command = 110 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be uploads. if msg->Data = 0, then uploads will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 111> DT_DOWNLOADS Allows you to retrieve or change number of userdownloads. msg->Command = 111 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be downloads. if msg->Data = 0, then downloads will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 112> DT_TIMESCALLED Allows you to retrieve or change number of usercalls. msg->Command = 112 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be timescalled. if msg->Data = 0, then timescalled will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 113> DT_TIMELASTON Allows you to retrieve or change time user last called. msg->Command = 113 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be timescalled. if msg->Data = 0, then timescalled will be msg->String. NOTE: This is not a date stamp, this is the number of seconds since January 19something. ------------------------------------------------------------------------ <FUNCTION #: 114> DT_TIMEUSED Allows you to retrieve or change timeused today. msg->Command = 114 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be timeused. if msg->Data = 0, then timeused will be msg->String. NOTE: This is in seconds. ------------------------------------------------------------------------ <FUNCTION #: 115> DT_TIMELIMIT Allows you to retrieve or change timeallowed for a user. msg->Command = 115 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be timelimit. if msg->Data = 0, then timelimit will be msg->String. NOTE: Time in seconds. ------------------------------------------------------------------------ <FUNCTION #: 116> DT_TIMETOTAL Allows you to retrive or change total time remaining. for a user today. msg->Command = 116 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be time remaining. if msg->Data = 0, then time remaining will be msg->String. NOTE: Time in seconds. ------------------------------------------------------------------------ <FUNCTION #: 117> DT_BYTESUPLOAD Allows you to retrieve or change bytes uploads per user. msg->Command = 117 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be bytesuploaded. if msg->Data = 0, then bytesuploaded will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 118> DT_BYTEDOWNLOAD Allows you to retrieve or change bytes downloaded per user. msg->Command = 118 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be bytesdownloaded. if msg->Data = 0, then bytesdownloaded will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 119> DT_DAILYBYTELIMIT Allows you to retrieve or change a users daily byte download limit. msg->Command = 119 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be bytelimit. if msg->Data = 0, then bytelimit will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 120> DT_DAILYBYTEDLD Allows you to retrieve or change daily bytes downloaded. msg->Command = 120 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be dailybytes. if msg->Data = 0, then dailybytes will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 121> DT_EXPERT Allows you to retrieve or change expert mode. msg->Command = 121 msg->Data = 1 or 0 ------------------------------------------------------------------------ <FUNCTION #: 122> DT_LINELENGTH Allows you to retrieve or change user linelength specs. msg->Command = 122 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be linelength. if msg->Data = 0, then linelength will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 123> ACTIVE_NODES Allows you to retrieve a string of active&inactive nodes. msg->Command = 123 msg->Data = N/A msg->String will be a string 10 bytes in length, with 'X's marking the active nodes. NOTE: This command will surely be changing, the current limit is 9 nodes. ------------------------------------------------------------------------ <FUNCTION #: 124> DT_DUMP Allows you to dump the user's data structure to a specified file. msg->Command = 124 msg->String = FileName ------------------------------------------------------------------------ <FUNCTION #: 125> DT_TIMEOUT Allows you to retrieve or change the door timeout limit. msg->Command = 125 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will equal timeout. if msg->Data = 0, then timeout will equal msg->String. NOTE: This time is in seconds. ------------------------------------------------------------------------ <FUNCTION #: 126> BB_CONFNAME Allows you to retrieve or change the conference name. msg->Command = 126 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be name. if msg->Data = 0, then name will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 127> BB_CONFLOCAL Allows you to retrieve or change the conference location. msg->Command = 127 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be location. if msg->Data = 0, then location will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 128> BB_LOCAL Allows you to retrieve the current BBS location. msg->Command = 128 msg->Data = N/A ------------------------------------------------------------------------ <FUNCTION #: 129> BB_STATUS Allows you to retrieve the current status of the node. msg->Command = 129 msg->Data = N/A msg->String will be 'OFFLINE' or 'ONLINE' depending on whether a user is logged onto the node. ------------------------------------------------------------------------ <FUNCTION #: 130> BB_COMMAND Obsolete, DO NOT USE msg->Command = 130 ------------------------------------------------------------------------ <FUNCTION #: 131> BB_MAINLINE Allows you to retrieve the menu prompt arguments prior to the door being entered. msg->Command = 131 msg->Data = N/A msg->String will be the menu prompt arguments. ------------------------------------------------------------------------ <FUNCTION #: 132> NB_LOAD Obsolete, DO NOT USE msg->Command = 132 ------------------------------------------------------------------------ <FUNCTION #: 133> DT_USERLOAD Obsolete, DO NOT USE msg->Command = 133 ------------------------------------------------------------------------ <FUNCTION #: 134> BB_CONFIG Obsolete, DO NOT USE msg->Command = 134 ------------------------------------------------------------------------ <FUNCTION #: 135> CHG_USER Obsolete, DO NOT USE msg->Command = 135 ------------------------------------------------------------------------ <FUNCTION #: 136> RETURNCOMMAND Allows you to specify an internal command to be executed when the door is finished. msg->Command = 136 msg->Data = N/A command to be executed will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 137> ZMODEMSEND Allows you to send files to the user via Zmodem protocol. msg->Command = 137 msg->String = filename (complete pathname) msg->Data = N/A result of transfer will be in msg->Data, where if msg->Data = 1 , then transfer successful. if msg->Data = -2, then user lost carrier. if msg->Data = 0 , then transfer unsuccessful. ------------------------------------------------------------------------ <FUNCTION #: 138> ZMODEMRECEIVE Allows you to receive batch uploads via Zmodem protocol. msg->Command = 138 msg->String = receive directory path msg->Data = N/A result of transfer will be in msg->Data, where if msg->Data = 1 , then transfer successful. if msg->Data = -2, then user lost carrier. if msg->Data = 0, then transfer unsuccessful. ------------------------------------------------------------------------ <FUNCTION #: 139> SCREEN_ADDRESS Allows you to retrieve the screen address. msg->Command = 139 msg->Data = N/A msg->String will be a string containing the hexadecimal address of the Node screen. ------------------------------------------------------------------------ <FUNCTION #: 140> BB_TASKPRI Allows you to retrieve the priority the node is running at. msg->Command = 140 msg->Data = N/A msg->String will contain the priority of the node. ------------------------------------------------------------------------ <FUNCTION #: 141> RAWSCREEN_ADDRESS Allows you to retrieve the screen address of the node. msg->Command = 141 msg->Data = N/A msg->String will be a string containing the decimal address of the express node. ------------------------------------------------------------------------ <FUNCTION #: 142> BB_CHATFLAG Allows you to retrieve the current chat setting. msg->Command = 142 msg->Data = N/A msg->String will be "ON" or "OFF". ------------------------------------------------------------------------ <FUNCTION #: 143> DT_STAMP_LASTO Allows you to retrieve a date string containing the date of when the user last logged on. msg->Command = 143 msg->Data = N/A msg->String will be the date string. ------------------------------------------------------------------------ <FUNCTION #: 144> DT_STAMP_CTIME Allows you to retrieve a current time string. msg->Command = 144 msg->Data = N/A msg->String will be a current time string. ------------------------------------------------------------------------ <FUNCTION #: 145> DT_CURR_TIME Allows you to retrieve the current time in seconds since January something. msg->Command = 145 msg->Data = N/A msg->String will be the current time. ------------------------------------------------------------------------ <FUNCTION #: 146> DT_CONFACCESS Allows you to retrieve the users conference access. msg->Command = 146 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be access string. if msg->Data = 0, then access string will be msg->String. NOTE: string consists of upto 9 'X' or '_'. ie: 123456789 --------- X_XXXX_XX <-- 'X' = access, '_' = no access ------------------------------------------------------------------------ <FUNCTION #: 147> BB_PCONFLOCAL Reserved, DO NOT USE msg->Command = 147 ------------------------------------------------------------------------ <FUNCTION #: 148> BB_PCONFNAME Reserved, DO NOT USE msg->Command = 148 ------------------------------------------------------------------------ <FUNCTION #: 149> BB_NODEID Allows you to retrieve the Node number for the current node msg->Command = 149 msg->Data = N/A msg->String will be the node number. ------------------------------------------------------------------------ <FUNCTION #: 150> BB_CALLERSLOG Allows you to add a line of text to the callerslog. msg->Command = 150 msg->String = text msg->Data = N/A ------------------------------------------------------------------------ <FUNCTION #: 151> BB_UDLOG Allows you to add a line of text to the udlog. msg->Command = 151 msg->String = text msg->Data = N/A ------------------------------------------------------------------------ <FUNCTION #: 152> EXPRESS_VERSION Allows you to retrieve the current version string of express. msg->Command = 152 msg->Data = N/A ------------------------------------------------------------------------- <FUNCTION #: 153> SV_UNICONIFY Reserved, DO NOT USE without first consulting the author msg->Command = 153 ------------------------------------------------------------------------- <FUNCTION #: 162> BB_CHATSET Allows you to retrieve or change the chat status. msg->Command = 162 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be current status. if msg->Data = 0, then status will be msg->String. ------------------------------------------------------------------------- <FUNCTION #: 162> ENVSTAT Allows you to retrieve or change the current environment stat variable code. msg->Command = 163 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be status. if msg->Data = 0, then status will be msg->String. ------------------------------------------------------------------------- <FUNCTION #: 500> GETKEY Reserved, DO NOT USE. msg->Command = 500 ------------------------------------------------------------------------- <FUNCTION #: 501> RAWARROW Reserved, DO NOT USE. msg->Command = 501 ------------------------------------------------------------------------- <FUNCTION #: 502> CHAIN Reserved, DO NOT USE. msg->Command = 502 ------------------------------------------------------------------------ <FUNCTION #: 503> NODE_DEVICE Allows you to retrieve the node device name. msg->Command = 503 msg->Data = N/A msg->String will be the device string. ------------------------------------------------------------------------ <FUNCTION #: 504> NODE_UNIT Allows you to retrieve the node unit number. msg->Command = 504 msg->Data = N/A msg->String will be the current node number. ------------------------------------------------------------------------ <FUNCTION #: 505> NODE_BAUD Allows you to retieve the initialized baud rate of the node. msg->Command = 505 msg->Data = N/A msg->String will be the init baud rate. ------------------------------------------------------------------------ <FUNCTION #: 506> NODE_NUMBER Obsolete, DO NOT USE. msg->Command = 506 ------------------------------------------------------------------------ <FUNCTION #: 507> JH_MCI Allows you to send mci text to express. msg->Command = 507 msg->String = text msg->Data = N/A ------------------------------------------------------------------------ <FUNCTION #: 508> PRV_COMMAND Allows you to immediately execute an internal express menu command. msg->Command = 508 msg->String = commandstring msg->Data = N/A ------------------------------------------------------------------------ <FUNCTION #: 509> PRV_GROUP Reserved, DO NOT USE. msg->Command = 509 ------------------------------------------------------------------------ <FUNCTION #: 510> BB_CONFNUM Allows you to retrieve the current conference number. msg->Command = 510 msg->Data = N/A msg->String will be conference number ranging from 0 to 8. ------------------------------------------------------------------------ <FUNCTION #: 511> BB_DROPDTR Allows you to drop carrier on a user. msg->Command = 511 msg->Data = N/A ------------------------------------------------------------------------ <FUNCTION #: 512> BB_GETTASK Finds the current nodes task address. msg->Command = 512 msg->Data = N/A msg->task will be the express task address. ------------------------------------------------------------------------ <FUNCTION #: 513> BB_REMOVEPORT Obsolete, DO NOT USE. msg->Command = 513 ------------------------------------------------------------------------ <FUNCTION #: 514> BB_SOPT Obsolete, DO NOT USE. msg->Command = 514 ------------------------------------------------------------------------ <FUNCTION #: 516> NODE_BAUDRATE Allows you to retrieve the current users connect rate msg->Command = 516 msg->Data = N/A msg->String will be the connect rate ------------------------------------------------------------------------ <FUNCTION #: 517> BB_LOGONTYPE Allows you to retrieve the LOGONTYPE. msg->Command = 517 msg->Data = N/A msg->Data will be: 0 = AWAIT_LOGON 1 = SYSOP_LOGON 2 = LOCAL_LOGON 3 = REMOTE_LOGON ------------------------------------------------------------------------ <FUNCTION #: 518> BB_SCRLEFT Allows you to retrieve the screen coordinates. msg->Command = 518 msg->Data = N/A msg->Data will be the Node's Initial leftedge coordinate. ------------------------------------------------------------------------ <FUNCTION #: 519> BB_SCRTOP Allows you to retrieve the screen coordinates. msg->Command = 519 msg->Data = N/A msg->Data will be the Node's Initial topedge coordinate. ------------------------------------------------------------------------ <FUNCTION #: 520> BB_SCRWIDTH Allows you to retrieve the screen coordinates. msg->Command = 520 msg->Data = N/A msg->Data will be the Node's Initial screen height. ------------------------------------------------------------------------ <FUNCTION #: 521> BB_SCRHEIGHT Allows you to retrieve the screen coordinates. msg->Command = 521 msg->Data = N/A msg->Data will be the Node's Initial screen width. ------------------------------------------------------------------------ <FUNCTION #: 522> BB_PURGELINE Allows you to abort serial input. msg->Command = 522 msg->Data = N/A aborts serial input and flushes the serial buffer and sends a request for more input. ------------------------------------------------------------------------ <FUNCTION #: 523> BB_PURGELINESTART Allows you to CLEAR the serial buffer and request more serial input. msg->Command = 523 msg->Data = N/A ------------------------------------------------------------------------ <FUNCTION #: 524> BB_PURGELINEEND Allows you to CLEAR the serial buffer. msg->Command = 524 msg->Data = N/A ------------------------------------------------------------------------ <FUNCTION #: 525> BB_NONSTOPTEXT Allows you to change the NONSTOP text scrolling flag. msg->Command = 525 msg->Data = 1 or 0 if msg->Data = 1, then display text will not pause. if msg->Data = 0, then display text will pause. ------------------------------------------------------------------------ <FUNCTION #: 526> BB_LINECOUNT Allows you to retrieve or change the user's current number of lines viewed. msg->Command = 526 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be current line. if msg->Data = 0, then current line will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 527> DT_LANGUAGE Allows you to retrieve or change the current language specifications. msg->Command = 527 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be language. if msg->Data = 0, then language will be msg->String. NOTE: Languages need to be standardized, please what for guidlines. ie: Default language .txt , .txt.gr English .Eng , .Eng.gr German .Ger , .Ger.gr note that this only effects the menus, bulletins & other screen text files. ------------------------------------------------------------------------ <FUNCTION #: 528> DT_QUICKFLAG Allows you to change the QUICKTEXT flag. msg->Command = 528 msg->Data = 1 or 0 if msg->Data = 1, then the QuickFlag will be set. if msg->Data = 0, then the QuickFlag will not be set. ------------------------------------------------------------------------ <FUNCTION #: 529> DT_GOODFILE Allows you to set the results of a tested file after upload. msg->Command = 529 msg->Data = 1,0 or -1 if msg->Data is 1, then the file was not tested. if msg->Data is 0, then the file passed the filetest. if msg->Data is -1, then the file failed the filetest. NOTE: This command is only useful with the sys.cmd door called FILECHECK. ________________________________________________________________________ <FUNCTION #: 608> QUICK_KEY Tries seeing which Key has been pressed on User Side, making it possible to detect things like CTRL-C or CTRL-X pressing in a door. msg->Command = 608 msg->Data = not needed msg->String = not needed It's give these values back: msg-> = -1 if Carrier Lost Otherwise, it should give back the DECIMAL VALUE of the key pressed. (Example: \003 would be the return value for a CTRL-C) using "C" code. This should be same way /X V3-4x is working. ------------------------------------------------------------------------ <FUNCTION #: 900> DT_CONFACCESS Allow you to retrieve the users conference access. msg->Command = 900 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be real access string if msg->Data = 0, the access string will be msg->String msg->String = string consists of upto 25 'X' or '_' EXAMPLE: 1234567890123456789012345 ------------------------- X_XXXX_XXXXX_X_X___XXXX_X ^ ^ |-'X'=ACCESS |-'_'=NO ACCESS ------------------------------------------------------------------------ <FUNCTION #: 901> DT_CBYTESUPLOAD Allows you to retrieve or change bytes uploads per user in the current Conference msg->Command = 901 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be bytesuploaded. if msg->Data = 0, then bytesuploaded will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 902> DT_CBYTESDOWNLOAD Allows you to retrieve or change bytes downloaded per user in the current Conference msg->Command = 902 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be bytesdownloaded. if msg->Data = 0, then bytesdownloaded will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 903> DT_CFILESUPLOAD Allows you to retrieve or change number of useruploads in the current Conference msg->Command = 903 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be uploads. if msg->Data = 0, then uploads will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 904> DT_CFILESDOWNLOAD Allows you to retrieve or change number of userdownloads in the current Conference msg->Command = 904 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be downloads. if msg->Data = 0, then downloads will be msg->String. ------------------------------------------------------------------------ <FUNCTION #: 905> BB_CONFACCOUNT Allows you to retrieve the current Conf Accounting Setting Also possibility to turn it ON or OFF msg->Command = 905 msg->Data = 0 - will turn Conf Accounting OFF 1 - will turn Conf Accounting ON msg->String will be "ON" or "OFF". ------------------------------------------------------------------------ <FUNCTION #: 906> DT_CALLEDTODAY Allows you to retrieve or change number of Calls a User has made THIS Day. msg->Command = 906 msg->Data = 1 or 0 if msg->Data = 1, then msg->String will be timescalled. if msg->Data = 0, then timescalled will be msg->String. ------------------------------------------------------------------------ <ERRATA>.....not fully described This is one Steve put it so that #define EXPRESS VERION 152 #define SXVERSION 907 existed so that the "ACTUAL" is 907 but the "fake" we created to make all /X V2+ doors compatable shows as V2.3+ <FUNCTION #: 907> ..............not yet adequately documented............ ------------------------------------------------------------------------ <FUNCTION #: 908> SIG_PLAYPEN Allow you to retrieve the Pathname of the PlayPen if the SysOP used a different one than the default Playpen. msg->Command = 908 msg->String = String will contain the PathName. Example: DH1:Node1/Playpen/ ------------------------------------------------------------------------ <FUNCTION #: 909> ICONIFYQUERY Allow you to retrieve the Status of the Current Node's Window, i.e. "Iconified" or "Active" msg->Command = 909 msg->String = YES or NO, depending on whether it is "iconified" or not. ------------------------------------------------------------------------ <FUNCTION #: 910> LOGON_UNAME Used for the NEW USERFRONT System Door/Module. Will check/load the Username stored in msg->String msg->Command = 910 msg->String = String to Check for. if msg->Data = 1, then User does not exist. if msg->Data = 0, then User does exist. **NOTE** This function is only to be used with USERFRONT Door, otherwise it could cause some problems. ------------------------------------------------------------------------ <FUNCTION #: 911> LOGON_UPASS Used for the NEW USERFRONT System Door/Module. Will check/load the Password of the User specified using the LOGON_UNAME Part described above. msg->Command = 911 msg->String = String to Check for. if msg->Data = 1, then Password is WRONG. if msg->Data = 0, then Password is CORRECT. **NOTE** This function is only to bbe used with USERFRONT Door, otherwise it could cause some problems. ------------------------------------------------------------------------ <FUNCTION #: 912> SIG_LI Request a Line Input from User. Works like JH_HK just that it wont display the Characters entered instead it will show Dots (".") - Just like on a PW Prompt. msg->Command = 912 msg->Data = Amount of Maximum Chars to be entered. ------------------------------------------------------------------------ <FUNCTION #: 1000> DT_ADDBIT Reserved, DO NOT USE. msg->Command = 1000 ------------------------------------------------------------------------ <FUNCTION #: 1001> DT_REMBIT Reserved, DO NOT USE. msg->Command = 1001 ------------------------------------------------------------------------ <FUNCTION #: 1002> DT_QUERYBIT Reserved, DO NOT USE. msg->Command = 1002 ---------------------------------------------------------------------------- NOTE!!!!!,, VERY IMPORTANT!!! DO NOT USE ANY COMMANDS THAT ARE NOT DOCUMENTED, SERIOUS PROBLEMS COULD OCCUR. The commands that are Obsolete or Reserved do not use either. 16. CHAPTER 16 Misc. Information on /X and S!X of Interest ====================================================== ***************************************************************** CHAPTER 16 Misc. Information on /X and S!X of Interest ***************************************************************** A. USING "REVISION.DOC".......portions still not completely incorporated correctly into your S!X Manual. Sorry :^)) <FROM: V0.39d6> Yyou`ll now also get a sexpress.catalogue File in each Update which you`d have to put into your locale:catalogue Directory (i guess hehe). aswell as a sexpress.cd / sexpress.ct File. the sexpress.cd shows you which Text Files you can create. at this Time its not allowed to change the Order of the %s %d etc Kind of ASCII`s. I`ll make it soon so you can change that too.. I`ll supply a Utilitie called CATEDIT to Edit the Catalogue - maybe two of them. BETTER DOCUMENTS ABOUT THAT SOON! <FROM: V0.39d9> Inserted a small SYSOPLOG - This is ALWAYS on, maybe (!) soon as an Option. The Sysoplog contains every Info on Account Changes including the NAME of the Co-Sysop/Sysop changing a Users Informations. (This ones for you Ped!) <FROM: V0.39e> Changed the Express to ALWAYS use the .catalog File - even if the defaults set to ENGLISH (previously it would not accept the .catalog Files in the locale:catalogs/english/ drawer if the WB Language would be set to english.) <FROM: V0.39j> First preparation for FAX RECEIVE!........certainly not finished as of V0.39u6 Made it possible to reserve a Port for a User from the Remote Side. All you need to do is save a Text called RESERVENAME to the Port Directory of the Port you wish to be reserved and tell the ACP to tell the Express to check for it. (i`ll supply a Source Code of my example Reserver.XIM if you need it.) <FROM: V0.39l6> Put the Sent By String into the sexpress.catalog Put the Extention Default for Text Files into the sexpress.catalog (eg: Bull.txt - The TXT is in Catalog.. so if you change it in a different Catalog for say German Language to GER it`ll try to display Bull.ger instead of Bull.txt (if it doesnt find it it`ll drop back to Bull.txt)) Put the MENU Line into the Catalog. Some may want to change it. <NO_DEF> We never really have defined what CONF.DB and CONF.DB.TOP really do and what information is stored within them........this whole subject needs a full explanation whether it is automatically created or not...... <FROM: V0.39m> Put in a Routine to automatically create the Conf.DB File(s) if they are non-existant. - Means the CONFDB Tool is not needed anymore. <FROM: V0.39n3> Changed the Way Express is initializing the Modems, now a Instant Login with an already Connected Modem can be done. Example: ------------------------------------------------------------------------- You have been calling out with your Favorite Terminal Program. Now a Call to the BBS comes in, you`ll see RING on your Terminal Screen now before you could not let that Caller in without letting him Call back after the Port is initialized again. Solution for now: Just enter ATE0 <RETURN> <- to turn the Echo Mode OFF ATA <RETURN> <- give Carrier after the Connection has been established you can tell the Guy on the other Side to wait a few Seconds. Now load up your Port in the Background, after it says Awaiting Connect quit the Terminal Program, uniconify (if required) the Port and Press F3 for Instant Login, at this Point the BBS should go on as if the User would have called the BBS in "normal State"... the User can go on as he would like to and didnt lose a Unit calling back... -------------------------------------------------------------------------- I hope this Explanation is brief enough to let you understand what i ment. By the Way, the above can only be done if the Terminal Program opened your Serial Device in shared Mode, and the Terminals Baud Rate is EXACTLY the same as for your BBS. IF NOT LET ME KNOW!... <FROM: V0.39o3> Express now checks for a File in the BBS:Node<x>/ Directory called BYEBYE, if existant it`ll simply HANG UP on the Caller on that Port (Just preparation for an Easy ByeBye Door.. requested by a "few" Guys Main "Bugging" to the Coder was done by Wing Leader and Dragon Avenger) <FROM: V0.39z2> Express is now searching for ENV:ByeBye.<NodeNumber> instead of BBS:Node<x>/ByeBye - Programmers please change it, Tests have proven that it is better to have these Files in ENV: than in BBS:Node<x> (less Disk Activity on Uploads) ===================================================================== <FROM: V0.39o9> Built in Global MailREAD, FileSCAN, ZippySEARCH. Arguments should have a "G" behind.. example: "N S G", "Z <pattern> G", "R G" <FROM: V0.39p> (04-17-95) " As a Test/Preview of a New Option i put in the possibility to NOT let the User ask for the File he wishes to upload (since ZModem AND Hydra is automatically detecting the Filename anyhow and the User is able to rename it incase the Filename is too big), to enable this just put a File called "NoPreDesc" into the BBS: Directory, NOTE: Just a TEST/PREVIEW... if there is a need i`ll make it so the Sysop can select it from the ACP.STARTUP (SUGGESTED by: The Crackin` Ltd *AND* Immortal (Just being lazy to do it)) Included a Routine to REMEMBER the Flagged Files, still in Progress but already working, The Flagged Files List will be stored to BBS:FlaggedFiles/ Directory with the Name <USERNUMBER>_FlagList it will or lets say does contain the Files that have been flagged (logic duh!) , the List looks like this: File1 File2 File3 ... ... each File is separated by a SPACE! - C-Programmers may want to use stptok() to get the Filenames, look into your Handbook, i am probably going to change the Way it is storing it so you just will have to read it in Line by Line, but thats still just a Thought. <FROM: V0.39p2> (04-24-95) " On Wildcard Selections for Downloads SigmaExpress will now ask for each File. like this: CAUCTIO1.TXT 6825 Bytes ( 6K), 0 mins 1 secs (Yes/No/Done) ? Ok, i know it looks a bit stupid, but i am working on the "Design".. nevermind, if the User chooses Yes it`ll continue searching for the next File and will prompt that one to him too, same goes for "No". if the User chooses "D"one - it`ll stop searching and will go onto the normal Fileselection Line for downloading. This was a suggestion by Elvin and since i got bored i "quickly" installed it >>STILL NEEDS TO BE TESTED MORE CAREFULLY<< (even tho it seems to work fine <NO_DEF> <FROM: V0.39p4> (05-04-95) " Fixed a small Bug with the "NODISPLAY" Option for FileChecking... had a small return() ayt the WRONG Place, making it NOT Check the Archive if NODISPLAY File was found in BBS: Directory... <NO_DEF> <FROM: V03.9p7> We really have not described in ANY FASHION WHATSOEVER what BBS:user.misc does/contains/etc. Even CONF.DB is a complete "??Unknown??" <FROM: V0.39q1> (06-23-95) " <BUG> Don't redirect to a "non-Existant" command or get STACK OVERFLOW!! Don't redirect at itself either..... New Doortype: "I"nternal - just as in /X you can now "redirect" a command entered on the Menu Prompt to an internal Command e.g: 1234567890123456... F IM001N would redirect the "F" Command for FileListings to the "N" Command for NewFiles... <FROM: V0.39q5> (07-06-95) " <NO_DEF> Also the Files FORWARDMAIL, FREEDOWNLOADS are going to be checked each Time you enter a Conference, before this was also done just at each Booting up of a Node, you couldnt make any Changes to it when the System was up, this is fixed and a lot more flexible now. <FROM: V0.39r6> (09-08-95) " In case of using the Conference Editor (which is in the Support Conference on my BBS) you can now choose a alternate MsgBase Path, aswell as a internal Password Function, plus the BBS would load in all of the Conference Informations each Time a User Logs on, you wont have to reboot anymore in case you change a Conference`s Name, Password, Location or some other Option. <NO_DEF> ENCRYPTED PASSWORDS....see Revision Doc from version 0.39x forward <NO_DEF> 39z3. " Version 0.39z3 (07-16-96) " New Option for the ACP.Startup File: NODE<x> RINGCOUNTS <y> <x> = The Node Number or '*' for ALL Nodes <y> = The Amount of RING`s before the Node should send the Answer String to the Modem. Should be useful in some Cases (e.g. Telnet Nodes with Problems of answering an incoming Call, weird Phoneline Problems etc) Note: You also need the new ACP - Note #2: You HAVE to set the RINGCOUNTS in the ACP.StartUp File!! Fixed a Bug with the ASCII Send Function (Shift-F4) - was trying to find a File with a Space added behind. Works again now. Btw: The '5' Command seems broken too (slightly), in the meantime just use '5 <directory path>' instead. Same goes for '2' (so i heard...). Just checked the '2' Command, works fine on my End, People may try to check if they actually have a Node0 Directory, i think if it doesnt exist it would abort/skip the Rest... Note to myself: Need to change the Routine for that 2! Implemented a new MCI Command Sequence: ~SQ_<Filename>| Will show the specified Filename in nonstop Mode. Needs to be tested first tho. Added something else (well, not my own Idea tho.. :)): If a User enters his Password false for the 3rd Time it will set a Flag in the User Data, next Time he calls he will only have ONE Try to enter his PW correctly, if he succeeds he will be notified that there was a Hack Attempt on his Account and the Flag will be reset. (Courtesy Tempest BBS) @NODE 39z5. " Version 0.39z5 (07-21-96) " Okay, Data-Stream actually found a BUG in the Revision.Doc (first Time, hopefully the last one too.. apart from forgetting to include Links) The File that is going to be displayed when a User had a Hack Attempt on his Account is NOT called BBS:BBSTEXTS/HACK.TXT but instead its BBS:BBSTexts/HackED.txt - Sorry for any Inconvience! Interphase reported a small "Flaw" where Express would not show the "Sysop is selecting Files..." Text to the User, this is fixed now. Express will now show a Text File called Hack.Txt in the BBSTexts Directory in case of an Hack Attempt, should be more visible than just a String. If the text File is not available, Express will just show the usual "There was a Hack Attempt" String to the User and Pause. (Suggested by Data-Stream) @NODE 39z6. " Version 0.39z6 (08-07-96) " OLM.Message.Txt will now also be displayed if the User selected 'Q'uick Logoff at the Transfer Start. Before it would drop Carrier on him without displaying that File. (Suggested by Noisy Belch) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~